On Wed, 19 Feb 2003, Will Benton wrote:

> On Wed, Feb 19, 2003 at 11:45:52AM -0600, Brian Hurt wrote:
> 
> > A better approach is what's called the M-by-N approach.  You have M kernel 
> > level threads (so you can take advantage of M parallel CPUs) each 
> > executing threads from a pool of N user space threads.  This gives you the 
> > best of both worlds.
> 
> Not necessarily -- most m:n threads packages have non-preemptive user
> thread schedulers, which means that a compute-intensive user thread that
> never enters the kernel and doesn't yield the processor can monopolize
> a kernel thread.  That might be a pathological example (since if
> you're trying to run >N compute-intensive threads on N processors,
> you're in trouble), but someone might argue that an application that
> context-switches enough to *require* m:n instead of 1:1 is
> pathological in a different way.

Co-operative scheduling is easier- but does run into the problem you point 
out, with the possibility of deadlock.

> 
> If you need preemptability, then the best-of-both-worlds approach is
> to find a system on which kernel thread context switches are cheap.
> :-)  (Making KT switches cheap seems to be the direction that the
> industry is going -- Sun, for example, has dropped their m:n threads
> package for solaris.)
> 

Part of the of the question is "what do you mean by 'cheap'"?  The last 
time I had firm numbers of how much a true task switch cost was the i386- 
and that was 300-500 clock cycles.  Which on a 33MHz machine was a 
signifigant cost.  300-500 clocks on a 3GHz machine is signifigantly 
cheaper- in fact, 300 clocks is about the cost of an unpredictable cache 
miss on the P4.  Also, large portions of the cost of a task switch is 
related to swapping out the memory map- cache and TLB misses and flushing.
If you're swapping between different processes with the same memory space 
(i.e. you don't have to flush TLB or cache), then I could see the cost 
being close to the cost of just saving/restoring the registers- i.e. about 
30-60 clock cycles.

I could easily see Sun saying that it wasn't worth it to do true M:N in 
the face of this.  The savings just aren't signifigant enough to make it 
worthwhile- *if* your operating systems can handle 1,000s of threads 
(until recently, Linux couldn't).  Solaris definately can.

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners