OSDev.org

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.

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.

I think we have totally different goals here
In fact, I'll probably have support for TCP/IP before I even bother to think about cursor control on the text-console.

I also have no reason to hurry. I am currently doing completely unrelated research which I believe will nontheless help me with my OS project in the future. I wouldn't be surprised if there was a code-generation script instead of human readable source-code for my kernel. Oh, well..

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

Brendan wrote: 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).

Well, my idea of server here means something like "consider yourself lucky if it'll support local textmode console for anything but debug log"

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.

Yeah, I was referring to the fact that you need some memory if you want to actually create 64k+ threads. That said, nothing huge really.

Embedded systems are a completely different area... I couldn't even load my micro-kernel in 64 Kb .

Well.. the kernel I mentioned which refuces to boot under 8MB is a micro-kernel too. That said, it frees most of that after boot, unless you have a few GB of memory on the system, in which case it pretty much does not matter.

Couldn't care less at this point really. It's mostly because of stupid initialization code anyway.