lkml.org 
[lkml]   [1999]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.353 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site