bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread model


From: Neal H. Walfield
Subject: Re: Thread model
Date: Mon, 17 Mar 2008 10:47:40 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Sun, 16 Mar 2008 08:21:19 +0100,
<olafBuddenhagen@gmx.net> wrote:
> On Wed, Mar 12, 2008 at 05:12:03PM +0100, Marcus Brinkmann wrote:
> 
> > As for the threading model, more than one kernel thread per real CPU
> > doesn't seem to make much sense in most cases.
> 
> Well, add a "per processing step" to make this statement more generally
> true. In some cases, it's useful to have a distinct set of worker
> threads for each processing step, working in a assemly line like fashion
> each thread picks a request from one wait queue, does it's work, and
> pushes it to the next wait queue.
> 
> This model specifically should improve performance for servers that are
> constantly busy, processing many requests in parallel; and under the
> condition that the amount of data touched in the processing is
> relatively small compared to the amount of code.
> 
> It also simplifies control flow and locking. Certain optimisations
> become obvious.

What sort of optimizations?  It seems to me that if you have a small
amount of data, then you'll be able to run almostly entirely out of
the L2 cache.  In this case, switching to another thread will
introduce the overhead of shifting the cache to the other CPU.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]