Date: Thu, 3 Oct 1996 15:06:09 +0100 (BST) From: Doug Rabson <dfr@render.com> To: dyson@freebsd.org Cc: Mikael Karpberg <karpen@ocean.campus.luth.se>, bde@zeta.org.au, heo@cslsun10.sogang.ac.kr, freebsd-fs@freebsd.org Subject: Re: nbuf in buffer cache Message-ID: <Pine.BSF.3.95.961003150224.10204R-100000@minnow.render.com> In-Reply-To: <199610031320.IAA00624@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961003150224.10204R-100000>