Date: Wed, 2 Oct 1996 14:50:39 +1000 From: Bruce Evans <bde@zeta.org.au> To: heo@cslsun10.sogang.ac.kr, toor@dyson.iquest.net Cc: freebsd-fs@FreeBSD.org Subject: Re: nbuf in buffer cache Message-ID: <199610020450.OAA23573@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Why does the number of buffers is calculated in this fashion? >> 30 buffers, 1024 pages, and division by 12 have special meaning? >> There is no comment on source code. >> >Experience shows that this is a good number. 30 Buffers is a good minimum >on a very small system. There has been problems in earlier code (and >perhaps even -current) when running with less than 10 Buffers. >> >The performance on a small system is poor (IMO) anyway. Adding more buffers >will take more memory from runnable processes. Generally, common wisdom >and practice shows that it is best to minimize paging. 30 buffers represents >approx 240K (on a normally configured filesystem.) If there is more free Experience showed that 240K is about right for a 2MB system running FreeBSD.1.x, but 30 buffers is far too small. For file systems with a block size of 512 (e.g. msdos floppies), it can cache a whole 15K. For normal ufs file systems with a fragment size of 1K, 1K fragments are common for directories. >memory, the system will store cached data in memory not associated with >buffers. On a 4MB system, this is uncommon though. Unlike other *BSD's >the buffer cache isn't the only place that I/O cached data is stored. On >FreeBSD the buffer cache is best thought of as a mapping cache, and also the >upper limit of dirty buffer space. Free memory is used for caching both >file data and unused memory segments (.text,...). Now 240K is probably too much for metadata alone, but 30 buffers is still too small. Metadata blocks are usually small, so 30 buffers usually limits the amount of metadata cached to much less than 240K. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610020450.OAA23573>