*BSD News Article 28220


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