Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!panix!news.panix.com!not-for-mail From: tls@panix.com (Thor Lancelot Simon) Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc Subject: Re: User-space file systems. (Re: Linux vs BSD) Date: 8 Mar 1997 01:00:36 -0500 Organization: Panix Lines: 79 Message-ID: <5fqva4$mua@panix2.panix.com> References: <5e6qd5$ivq@cynic.portal.ca> <5fjek4$gtm@cynic.portal.ca> <5fl7gf$urs@pulp.ucs.ualberta.ca> <5flmlf$6a3@cynic.portal.ca> Reply-To: tls@rek.tjls.com NNTP-Posting-Host: panix2.panix.com X-Newsposter: trn 4.0-test55 (26 Feb 97) Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:163288 comp.os.linux.networking:71188 comp.os.linux.setup:101435 comp.unix.bsd.bsdi.misc:6251 comp.unix.bsd.misc:2748 In article <5flmlf$6a3@cynic.portal.ca>, Curt Sampson <cjs@cynic.portal.ca> wrote: >In article <5fl7gf$urs@pulp.ucs.ualberta.ca>, >J Gunthorpe <jgg@gpu3.srv.ualberta.ca> wrote: > >>The raw switch time perhaps, but follow the code path through and I >>imagine you'll observe that it's not just a protection switch that's being >>issued..... > >>Full User-User Switch Times: >>QNX 4.2 (P5/133) 1.73 secs, 57.65/millisec 17 microsec/switch >>Linux (P5/120) 5.59 secs, 17.90/millisec 56 microsec/switch > >Well, let's assume for the sake of argument that QNX is doing a >protection mode change with every kernel/user boundary crossing. >(I don't know if this is the case.) Assuming they've optimised it >so well that that 17 microseconds is mostly the protection mode >changes at two boundary crossings, we're talking about well over >30 microseconds spent doing boundary crossings for every NFS request. >A Pentium CPU can do a fair amount of work in 30 microseconds. Why >do you want to throw this work away? > >>As a trivial example consider a new kernel call 'transfer block from fd to >>fd' then the sequence would be only 1 and 2. > >Yup. You just need a bit of code to deal with the munging you need >to do when you do this block transfer from the disk fd to the >network fd, so that you get nfs out the network fd. Add another >quick bit of code to deal with requests, to save on that side of >it as well (so we've just saved 1 and 2), and we're set. Oops! >We've just put an NFS server in the kernel! > >>What about other filesystems, SMB (Samba), AFS, etc they all have the same >>use.. > >Indeed. That's probably why Network Applicance has SMB in their >machines as well. > >>If you ask me, there is a big gain to have have high speed >>user->kernel->wire->kernel->user transfers, much larger than having a fast >>NFS in the kernel. > >Of course, but given that speeding that up to a really significant >degree means chucking out your processor and replacing it with one >that doesn't have such a large hit for a protection mode swith, I >think I'll stick with the software solution. > >>: As for the `monolithic bloatware kernel,' you already have that, >>: according to the microkernel people. On the other hand, you also >>: have a faster kernel than the microkernel people do. :-) >> >>I'm not sure about that (I've never seen any benchmarks either way),... Heh. Take a look at the paper on the straight-up port of Sprite to run on top of Mach 3.0. That's about as fair a comparison as you'll get, I think. > >That's all right. I am. If you doubt, compare, say, NetBSD to >Windows NT. (The easiest way to do this is to read the paper on >this in the Feb. '96 _ACM Transactions on Computing_.) Protection >mode switches kill NT performance. > The paper "The File System Belongs In The Kernel" from the Sprite project (I don't recall the author offhand) seems fairly appropriate here, as well. There are people out there in the real world right now who have networks that are fast enough that they have to worry about the speed of doing one or two copies per packet _in the kernel_. At least one of them works on NetBSD, and he can be a real PITA on any suggestion that adds latency to any of the networking code. Protection switches, on the i386 at least, are worse than small packet copies by at least an order of magnitude, so you can imagine what that might do to you on a gigabit network. -- Thor Lancelot Simon tls@rek.tjls.com But as he knew no bad language, he had called him all the names of common objects that he could think of, and had screamed: "You lamp! You towel! You plate!" and so on. --Sigmund Freud