From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA13808; Wed, 19 Feb 2003 20:16:58 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA13830 for ; Wed, 19 Feb 2003 20:16:56 +0100 (MET) Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1JJGsP28131 for ; Wed, 19 Feb 2003 20:16:55 +0100 (MET) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Feb 2003 13:15:38 -0600 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Feb 2003 13:15:37 -0600 Date: Wed, 19 Feb 2003 13:26:47 -0600 (CST) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Will Benton cc: Ocaml Mailing List Subject: Re: [Caml-list] Re: feature priorities (multithreading) In-Reply-To: <20030219121756.C2587@tux15.cs.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Feb 2003 19:15:37.0923 (UTC) FILETIME=[49086930:01C2D84B] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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