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!arclight.uoregon.edu!newsfeed.direct.ca!nntp.portal.ca!cynic.portal.ca!not-for-mail From: cjs@cynic.portal.ca (Curt Sampson) 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: 5 Mar 1997 22:02:23 -0800 Organization: Internet Portal Services, Inc. Lines: 61 Message-ID: <5flmlf$6a3@cynic.portal.ca> References: <5e6qd5$ivq@cynic.portal.ca> <5fj9q4$s0i@pulp.ucs.ualberta.ca> <5fjek4$gtm@cynic.portal.ca> <5fl7gf$urs@pulp.ucs.ualberta.ca> NNTP-Posting-Host: cynic.portal.ca Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:162947 comp.os.linux.networking:70961 comp.os.linux.setup:101103 comp.unix.bsd.bsdi.misc:6220 comp.unix.bsd.misc:2725 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),... 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. cjs -- Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite myst, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.