Messages in this thread | | | Date | Sat, 20 Feb 1999 16:09:27 +0000 | From | Jamie Lokier <> | Subject | Re: Asynchrony (was Re: Locking a process or thread onto a specific CPU) |
| |
David Wragg wrote: > (*) Given that few malloc calls take >1000 cycles, but to block a > thread in mutex_lock costs >1000 cycles, it *might* help for a thread > to backoff then retry once or twice when locking the malloc locks, but > it would only be a win on SMP, and it would need a real program that > can be demonstrated to suffer from heap contention to show benefit -- > does anyone have one?
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/
| |