- stephenmwParticipantAugust 9, 2020 at 10:23 pmPost count: 6
After watching the talk on threading, I have some questions related to number of possible threads. First, Ivan mentions that it may support 16 bits thread IDs. He also says that Go would work well with these threads, however, I don’t see how you could have enough threads. Some people run 100k or even 1,000,000 coroutines in Go, but 16bit would only give you 65k threads. Assuming a 65k limit, Go would need to limit thread usage and instead allocate its own stacklets which wouldn’t be in a WKR and use more PLB power. Allowing more threads is an option, but the more threads you allow, the less space is available per stacklet.
Going one step further, what would stop a user from spawning until no thread ids are left? I am guessing that in such a case there would be a trap and the OS would solve the problem? This could lead to reuse hazards so the policy model would need to take that into account somehow.
Would this also make virtualization impossible on a Mill? If I had a hypervisor (assume built just for Mill) running many copies of Linux, how would I control the use of thread IDs or even how much memory was used on a per guest basis? You could control how much of the address space you assign, but that wouldn’t include stacklets.
Speaking of virtualization, it seems like you would also have to figure out how to inform each process of the OS services location. For example, if there is an OS portal to spawn a process, how would an application know where to find that portal? This could be put in a “well known location” but that wouldn’t virtualize well when there is one virtual address space.
- Ivan GodardKeymasterAugust 10, 2020 at 12:52 amPost count: 629
It’s unclear whether Go on a Mill should map its threadlets onto Mill hardware threads; they may be too heavy-duty for Go use. Frankly, I don’t know enough about Go and its usage to say. One thing that’s safe to say is that no matter what size we choose for a thread id there will be someone who wants more threads. 🙂
Thread runaway is not only possible due to malice, but also due to program bug. In this a runaway spawn is much like runaway call, i.e. recursion and runaway malloc, and has the same fix: quotas.
As for virtualization, a virtualized Mill presents what appears to be a real Mill, which has a full shared virtual address space both to the app and to the (guest) kernel/OS. The hypervisor runs in another (real) Mill, with a full space disjoint from all the guest spaces, but has means by which it can see and manage the guests. How, you ask? Sorry, that’s NYF (Not Yet Filed).
- stephenmwParticipantAugust 10, 2020 at 4:27 pmPost count: 6
That makes sense. There is not yet shared information to handle virtualization. Hopefully it includes separate thread spaces!
- Ivan GodardKeymasterAugust 10, 2020 at 6:34 pmPost count: 629
Thread id, turf id, and address spaces are all virtualized. If we have any other kernel-known spaces they will be virtualized too.
The main advantage of the Mill ISA is that there are no privileged operations; all protection is by address using the PLB. Consequently it is immune to the endless corner cases that special ops cause for other ISAs.
You must be logged in to reply to this topic.