If the context switches are performed in userland, they should be much
faster than 1000 cycles. I expect multiple heaps will still be a win in
many cases, much as using different heaps for different object
types/sizes is often a win.
> I'd like to see a nice implementation of user-on-kernel-threads on
> Linux, but I'm really not sure it would be a win for typical pthreads
> C programs. When you say LinuxThreads loses against FreeBSD threads,
> is that for micro-benchmarks or real programs?
I don't know about typical pthreads programs. The "fast, really I mean
fast" threads that I'm talking about is indeed user-on-kernel-threads.
Kernel threads isn't even an option for the >50,000 threads I have in
mind. I'm not talking about being silly with threads here for the sake
of it. I'm talking about having >50,000 objects in a simulation, which
most of the time don't need a locally allocated stack or kernel context.
However, occasionally they do need one (when they block, or page to
disk).
The intention is (1) that a typical fast "schedule calling 50,000
objects' `think()' methods" list+heap scheduler runs most of the objects
efficiently (without individual stack frames); (2) some processing
continues even while paging; (3) a few objects can use operating system
services and get their own stack frame (on demand), while being able to
use the same mutex/semaphore/message services as the 50,000 simulated
objects.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/