Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uknet!festival!edcogsci!richard From: richard@cogsci.ed.ac.uk (Richard Tobin) Subject: Re: linux's I/O calls faster than NetBSD's ? Message-ID: <CMGCvw.ABF@cogsci.ed.ac.uk> Organization: HCRC, University of Edinburgh References: <2lhv9r$pbt@homea.ensta.fr> <2limt7$16k@homea.ensta.fr> <BE3J-z0.dysonj@delphi.com> Date: Thu, 10 Mar 1994 14:14:19 GMT Lines: 24 In article <BE3J-z0.dysonj@delphi.com> John Dyson <dysonj@delphi.com> writes: > So your observations are showing the limited size >of the *BSD buffer caches. This does indeed seem to be the explanation. If you reduce the file size so that it fits in the buffer cache, it runs as fast as you would expect. (Interestingly, under NetBSD 0.9 I had to reduce it to about half the buffer cache size for this to work, but under NetBSD current it worked up to the full size. Evidently buffer cache performance has improved between 0.9 and current.) While this means that Linux's buffer caching (which is presumably like SunOS's, where the whole of memory can be used for caching) is better than NetBSD's for your application, it isn't necessarily better for other situations. Unless carefully tuned (unlike SunOS!) this strategy may result in one application's i/o decreasing the available memory for other processes. It appears to be difficult to get a good balance. -- Richard -- Richard Tobin, HCRC, Edinburgh University R.Tobin@ed.ac.uk "Your monkey has got it right, sir." - HHGTTG