Hi,
mystran wrote:
Well, I actually could think of several reasons I personally MIGHT want more than 64k threads. Sure that takes some memory, but am aiming at server (and tentatively desktop) systems and I bet I'm not releasing anything usable before 64-bit system are common place anyway, so I don't find that as a problem.
I'm also aiming for desktop and server, but I've been having trouble distinguishing between "server" and "desktop" lately (other than by how robust the case is).
mystran wrote:
Also note, that being able to scale to a few hundred thousand threads does not necessarily mean you can't scale it down as well. I admit that my kernel refuces to boot with systems of less than 8 megabytes of ram, but I was never aiming for low memory requirements. I am more interested in building a system which is conceptually simple enough that it is easy to build powerful abstractions on top of it, so as to allow very complex tasks to become manageable.
It doesn't actually take memory unless all of the threads are in use (it only consumes linear address space). I'm aiming to have minumum memory requirement as 2 Mb (support for up to 64 Gb for the 32 bit/PAE version). Eventually (when the 32 bit version is "complete") the 64 bit version will support up to 16 million threads.
Dreamsmith wrote:
Different design goals, different rules. My OS should be ready to deploy in a few months, and the first serious use of it is going to involve me shoehorning it into a handheld unit with as little RAM as possible.
Embedded systems are a completely different area... I couldn't even load my micro-kernel in 64 Kb
.
Dreamsmith wrote:
This aside, however, it really ought to be noted that blocked processes shouldn't be counted against the segment descriptor limit. Creating and destroying segment descriptors on every task switch would be annoying, but creating and destroying segment descriptors as tasks and added or removed from the run queue is trivial. The descriptor limit really only significantly impacts the number of running tasks you can easily support (and even that isn't too hard to get around, really).
Dynamically modifying a single TSS descriptor is actually easier than you'd first think - roughly 4 instructions added to the task switching code.
Dreamsmith wrote:
To me, the best argument against hardware task switching involves the size of the TSS, which holds many more entries than I really need. Look at all those wasted bytes! *shudder*
For me it's performance (unnecessary segment limit checks, etc). I'm using 4 Kb instead, but that includes 512 bytes for FPU/MMX/SSE state save area, a > 2 Kb CPL=0/kernel stack and a pile of unrelated information (thread name, CPU time used, memory usage statistics, CPU affinity, etc). The FPU/MMX/SSE state save area and kernel stack make a 104 byte TSS seem tiny.
Cheers,
Brendan
