Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!inquo!nntp.uio.no!newsfeeds.sol.net!mr.net!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 01:32:52 -0800
Organization: Internet Portal Services, Inc.
Lines: 55
Message-ID: <5fjek4$gtm@cynic.portal.ca>
References: <5e6qd5$ivq@cynic.portal.ca> <5evsnm$1200@usenet1y.prodigy.net> <5f283t$667@cynic.portal.ca> <5fj9q4$s0i@pulp.ucs.ualberta.ca>
NNTP-Posting-Host: cynic.portal.ca
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:162799 comp.os.linux.networking:70881 comp.os.linux.setup:100976 comp.unix.bsd.bsdi.misc:6207 comp.unix.bsd.misc:2715
In article <5fj9q4$s0i@pulp.ucs.ualberta.ca>,
E Runeland <jgg@gpu4.srv.ualberta.ca> wrote:
>I think this discussion is quite interesting, but one point that no-one
>has brought up is quite simply, why does linux have such a slow protection
>switch time?
Um...because Linux, like all the other operating systems out there,
has no way to make a 386 switch protection modes any faster than
it currently does?
This is as much a processor issue as an operating system issue.
>Or perhaps even, how can we optimize the kernel calls so that only 1 per
>packet is required?
Well, how can you minimise the boundary crossings?
1. Kernel receives request. Kernel passes request to uses process.
[ kernel -> user transition ]
2. User process asks kernel to read disk block.
[ user -> kernel transition ]
3. Kernel passes disk block back to user process.
[ kernel -> user transition ]
4. User process passes response back to kernel.
[ user -> kernel transition ]
I don't see any way to avoid crossing the user/kernel boundaries
any fewer number of times unless you move the NFS daemon into the
kernel, or move either the disk I/O or the networking (or both)
into userland. The latter is obviously not terribly practical,
except perhaps for a dedicated NFS serving machine.
>Just moving the whole daemon into the kernel is a
>solution to speed problems, but by that same token other deamons that are
>'performace critical' (http, ftp etc) should be moved into the kernel and
>you end up with a monolithic bloatware kernel :<
If you were moving massive amounts of data over a local area network
with FTP or HTTP, yes, it might make sense to move them into the
kernel. But these protocols aren't generally used for that sort of
thing, and thus don't have the sort of performance issues that an
NFS server has to deal with. (If you do have that sort of performance
issue with http, such a solution has been developed: Network
Appliance boxen now do HTTP as well as NFS.)
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. :-)
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.