Date: Thu, 3 Oct 1996 10:05:45 +0200 (MET DST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: dyson@FreeBSD.org Cc: bde@zeta.org.au, heo@cslsun10.sogang.ac.kr, freebsd-fs@FreeBSD.org Subject: Re: nbuf in buffer cache Message-ID: <199610030805.KAA25133@ocean.campus.luth.se> In-Reply-To: <199610020511.AAA00199@dyson.iquest.net> from "John S. Dyson" at "Oct 2, 96 00:11:16 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! > memory as possible. If (and it is a very big if) there is free (spare) > memory, the system will provide it in the form of the merged VM object cache. > Note also the system prefers to keep metadata in the cache, and to push > file data to the VM objects. It is then the best of both worlds. > > So, to be precise, limiting the number of buffers keeps the freedom > maximized. The larger the number of buffers, the greater the chance that > there will be too much wired memory for an application. I have found that > the knee for gcc appears to be about 2M (plus or minus.) And it is very > sharp. If you restrict the amount of memory even by 100K-200K, compile > times go through the roof. > > Additionally, the issue of MSDOS having a very small cache size isn't valid, > and is limited by the total amount of available memory. 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? :-) /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610030805.KAA25133>