Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!ox-prg!culhua!mike From: mike@prg.ox.ac.uk (Mike Spivey) Newsgroups: comp.os.minix Subject: Re: Bigger buffer cache for PC MINIX Message-ID: Date: 22 Apr 91 10:22:21 GMT References: <1694@targon.UUCP> Sender: news@prg.ox.ac.uk Followup-To: comp.os.minix Distribution: comp Organization: Oxford University Computing Laboratory, UK Lines: 26 In-reply-to: gert@targon.UUCP's message of 19 Apr 91 10:22:31 GMT In article <1694@targon.UUCP> gert@targon.UUCP (Gert Kanis) writes: I was wondering just *how* big you made your buffer cache. P.S. On the 68000 system it's also possible to increase buffer cache. Just change the #define in minix/boot.h (or was it config.h ?). Recompile (FS ?) and build a kernel. I haven't tried different cache sizes, but I have 30 buffers internal to the fs and 256 external buffers; this leaves enough space for processes on my 1M machine. The internal buffers are used for directory blocks, super blocks, and other things the FS needs to access directly, rather than just copy to user space. Useful statistics are difficult to collect, partly because of the effects of read-ahead, but I have measured that more than half the fetches are for the internal cache. This suggests that a lot of the speed-up comes from not having directory blocks flushed from the internal cache by data blocks. Even on machines that have the address space to put a big cache inside the fs, I wonder if there may be some benefit in modifying the buffer allocation scheme to be kinder to directory blocks, indirect blocks, etc. than to data blocks. This would require changes to fs/cache.c to use information that is already provided as a parameter to put_block(). -- Mike Spivey