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 UAA17306; Thu, 1 May 2003 20:59:15 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA17365 for ; Thu, 1 May 2003 20:59:14 +0200 (MET DST) Received: from epexch01.qlogic.org ([63.170.40.3]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h41IxDH01394 for ; Thu, 1 May 2003 20:59:13 +0200 (MET DST) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 1 May 2003 13:58:21 -0500 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Thu, 1 May 2003 13:58:20 -0500 Date: Thu, 1 May 2003 14:08:09 -0500 (CDT) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Lex Stein cc: Ocaml Mailing List Subject: Re: [Caml-list] comparison with C performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 01 May 2003 18:58:20.0899 (UTC) FILETIME=[A23F5B30:01C31013] X-Spam: no; 0.00; qlogic:01 caml-list:01 nominal:99 tlb:99 ate:99 amiga:01 stunt:01 monolithic:01 kernels:01 plausible:01 latency:01 mappings:01 stein:01 slower:01 egan:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>From memory, task switches on the 386 were 300-500 clock cycles. By the time of the pentium, the nominal cost of a task switch was ~50 cycles IIRC, but this did not include the costs of the TLB and cache flushs. Which raised the question of how much work you did after the TLB determining how expensive the task switch was (and does those costs count to task switch costs anyways?). I don't beleive it's been signifigantly improved since then. Task switches can be a performance problem. This is, at heart, the problem with microkernel operating systems. Done "canonically" you are task switching constantly. Especially back in the day of the Torvalds-Tannenbaum debate, the task switch cost ate you alive. The successfull microkernels generally did without memory protection- an example here is the Amiga kernel. Microkernel, granted, but no memory protection either. Several realtime OSs do the same stunt. Or, in a slightly less extreme way, you can just move more stuff into the same task, reducing the number of task switches you need to make. This is the choice Microsoft made with NT, when they moved the core graphics routines into the kernel with NT4. I find it humorously that the "microkernel" NT has graphics in the kernel, while the "monolithic kernel" Linux keeps graphics in a user space application (X). But by pulling functions into the same task space, A) you are losing a number of advantages of microkernels (for example, a misbehaving driver can now crash the kernel), and B) you are starting to look an awful lot like a monolithic kernel. The successfull kernels today are actually hybrids of monolithic and microkernel, to one extent or another, at this point. On the other hand, task switching isn't nearly the cost of I/O- disk or network- which I would expect to dominate. That being said, limiting task switches is not the only plausible optimizations an in-kernel NFS server could implement. I haven't investigated this code, but some plausible explanations include interrupt/signal latency, scheduling advantages, few address mappings/reverse mappings, etc. Brian On Thu, 1 May 2003, Lex Stein wrote: > > My short answer is: No. > > Thanks > Lex > > > Wouldn't you expect any userspace nfs server to be much slower than the > > kernel-based implementation due to the overhead of all the extra > > context-switching? > > > > -- > > Miles Egan > > > > ------------------- > 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 > ------------------- 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