From owner-freebsd-fs Thu Oct 3 07:10:49 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA28917 for fs-outgoing; Thu, 3 Oct 1996 07:10:49 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA28759; Thu, 3 Oct 1996 07:08:43 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id PAA26204; Thu, 3 Oct 1996 15:06:09 +0100 Date: Thu, 3 Oct 1996 15:06:09 +0100 (BST) From: Doug Rabson To: dyson@freebsd.org cc: Mikael Karpberg , bde@zeta.org.au, heo@cslsun10.sogang.ac.kr, freebsd-fs@freebsd.org Subject: Re: nbuf in buffer cache In-Reply-To: <199610031320.IAA00624@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Oct 1996, John S. Dyson wrote: > > > > Umm... hold on a second, here... :-) > > I always thought Linux etc used all free memory for disk caching, and > > that the BSD's used a formula (basically something like some percentage of > > the available memory) to determine the size of a static buffer, used as > > disk cache. Now... it makes sense if this changes when you use a merged > > disk cache and VM system. Someone let me in on how things work? :-) > > > FreeBSD uses all of available memory for disk cache (it has actually had > a true merged VM/buffer cache longer than Linux.) Linux has used a dynamic > buffer cache for a long time though (which is technically different.) The > only type of data that must be in a buffer is directory info. I am about > ready to consider 2x-3x the number of buffers and changing a few tunables > so that the cache will not take any more space. Since buffers only take > 200 or so bytes apiece, it will not hurt (much) to increase the number of > buffers even on a small system. The perf won't go down as long as I change the > formula so that the memory limit isn't 8K * nbuf, but is 2-3K * nbuf. Having more buffers would improve performance for NFSv3 since data which has been written to the server but not committed is held in specially marked dirty buffers. Having a limited supply of buffers forces the system to commit data earlier, which involves another client-server round trip and a possible wait for the server's sync operation. It would be nice if instead of marking the buffer for a later commit, the underlying pages could be marked instead. This would be tricky to fit into the existing vnode system though. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426