Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!iafrica.com!pipex-sa.net!plug.news.pipex.net!pipex!tank.news.pipex.net!pipex!news.mathworks.com!nntp.primenet.com!news.sprintlink.net!news-stk-3.sprintlink.net!news.sprintlink.net!news-ana-24.sprintlink.net!news.sprintlink.net!news-ana-7.sprintlink.net!hpg30a.csc.cuhk.hk!news.cuhk.edu.hk!newsf eeder.ust.hk!nntp.hk.super.net!news.iij.ad.jp!news.CET.CO.JP!usenet From: Michael Hancock <michaelh@cet.co.jp> Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: vfs overhead? (was Re: TCP latency) Date: Sat, 20 Jul 1996 02:09:14 -0700 Organization: CET Lines: 40 Message-ID: <31F0A23A.1019@cet.co.jp> References: <4paedl$4bm@engnews2.Eng.Sun.COM> <31E80ACA.167EB0E7@dyson.iquest.net> <4sadde$qsv@linux.cs.Helsinki.FI> <31EA9FBC.41C67EA6@star-gate.com> <4sgo4l$ucf@linux.cs.Helsinki.FI> NNTP-Posting-Host: a07m.cet.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45826 comp.unix.bsd.netbsd.misc:4120 comp.unix.bsd.freebsd.misc:24009 Linus Torvalds wrote: > > Now, the factor of 3-4 doesn't necessarily tell the whole story, and it > has been claimed that some of the overhead of FreeBSD is the VFS > overhead. Linux just seems to handle that same overhead a lot better, > and WITHOUT needing to special case anything at all. I hope this doesn't cause the backing out of the FS Stacking work put into system since 4.4Lite. What can this do? Stack a mirroring layer, a compression layer, a crypto layer, a union mount layer, and do it on top of ffs,lfs,extfs, or whatever you come up with. And you can do it without having to rewrite a lot of code. This has extensible VOPs, etc. Basically, there are some classical performance vs. (flexibility/extensibility) tradeoffs here and hope this benchmark war doesn't cause the FreeBSD camp to only look at the performance dimension. The fs is one of the next great frontiers of development and the stuff that's in there is just too cool. If there is going to be any optimizations, lets work within this fundamental framework. Regarding the TCP/IP code there was talk about how the linear buffers in the Linux protocol stack might be a one of the reasons for the good numbers. Van Jacobson has mentioned this in his works. However, the performance gains don't seem to be that large over the linked list mbuf implementation in 4.4Lite. I don't think it would be worth it to do the large contiguous buffer thing at this time, especially after looking at the Berkeley research post. It would be a lot easier to merge in these developments if we don't make large changes to the existing system. -mike hancock