Date: Wed, 2 Oct 1996 16:18:46 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dyson@freebsd.org Cc: freebsd-fs@freebsd.org, heo@cslsun10.sogang.ac.kr Subject: Re: nbuf in buffer cache Message-ID: <199610020618.QAA26221@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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. >> >So, you would trade paging for file buffering? I don't think so. Firstly, the No, but allocate enough buffers to hold the memory that you're willing to allocate for (non VM-object) buffering. nbuf = memory_allowed / DEV_BSIZE is too many for static allocation, so dynamic allocation is required. sizeof(struct buf) is now 212, so the worst case should only have nbuf = memory_allowed / (512 + 212). (struct buf is bloated. In my first implementation of buffering, for an 8-bit system, DEV_BSIZE was 256 and sizeof(struct buf) was 13 and I thought that the 5% overhead was high. Sigh.) >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 Limiting the number of buffers instead of limiting the memory allocated for the buffers sometimes gives more freedom because less memory is allocated, but it is better to limit the amount allocated explicitly. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610020618.QAA26221>