mike@prg.ox.ac.uk (Mike Spivey) (04/02/91)
Some time ago, I suggested enlarging the buffer cache of PC MINIX by putting part of it outside the FS address space. I've now done this, and will post some patches if there's enough interest -- send mail if you'd like them. If nothing else, a bigger cache reduces the need for more concurrency in the file system. Here are some rough timings for different MINIX configurations. Neither cache nor RAM disk affects the `user' or `system' times much, since the machine mostly runs the idle process while the disk i/o happens. So I've just shown the elapsed times. KERNEL REBUILD (root on hard disk) big cache 6:59 /tmp on ram disk 7:21 bare (no ram disk) 7:42 Total user+sys was about 6 mins for all three. FACTOR TEST (see code below) root and /bin on ram disk 27 sec big cache 33 sec /bin on ram disk 42 sec bare (no ram or big cache) 59 sec The code (with all programs in /bin): a=2 while test $a -le 100 do echo -n $a "= " factor $a a=`expr $a + 1` done The cache seems to be a big win because (a) you don't have to choose what binaries to put on it and (b) you don't run out of space till the hard disk is full -- the performance goes down more gradually. It works especially well when you run lots of little programs together, in true UNIX style. Some suggested that these mods would make the FS intolerably slow, because it would always be having to trap to the kernel to copy buffers around, but I haven't found that to be the case. With a little care, one can organise things so that directory blocks, etc., are put in buffers inside the FS address space, and ordinary data blocks are outside the address space, so the almost the only copying is to and from user space -- copying that is done anyway. -- Mike Spivey
nicolas@cli52or.edf.fr (04/03/91)
> > Some time ago, I suggested enlarging the buffer cache of PC MINIX by > putting part of it outside the FS address space. I've now done this, > and will post some patches if there's enough interest -- send mail if > you'd like them. If nothing else, a bigger cache reduces the need for > more concurrency in the file system. > Interesting, interesting can you post ?
gert@targon.UUCP (Gert Kanis) (04/19/91)
In article <MIKE.91Apr2131128@client25.prg.ox.ac.uk> (Mike Spivey) writes: >Some time ago, I suggested enlarging the buffer cache of PC MINIX by >putting part of it outside the FS address space. I've now done this, > >Here are some rough timings for different MINIX configurations. > > KERNEL REBUILD (root on hard disk) > > big cache 6:59 > /tmp on ram disk 7:21 > bare (no ram disk) 7:42 [ .. more timings deleted ] > >-- Mike Spivey 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. +-------------------------------------------+ | Gert Kanis, AP SWZ | | Siemens Nixdorf Information systems | | P.O.box 29, 4130 EA Vianen, Netherlands. | | E-mail: [smart-mailer!]gert@targon.uucp | | or [..uunet!]hp4nl.nluug.nl!targon!gert| +-------------------------------------------+
mike@prg.ox.ac.uk (Mike Spivey) (04/22/91)
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 Spiveyroot@minixug.mugnet.org (MINIXUG-ONLINE System Manager) (04/25/91)
In article <1694@targon.UUCP>, gert@targon.UUCP (Gert Kanis) wrote: [ info about the new cache ] > I was wondering just *how* big you made your buffer cache. He used the "standard" define of 256 blocks. I added his code to the new release of the all-famous Advanced MINIX (certain people will now know what the expression on my face looks like right now :-). I changed the code to have a hardcoded "max" cache size (#define NR_XBUFS 1024), which can be set to a smaller number at BOOT time (using the also-famous Intelliboot bootloader's config record). Neat! > 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. Yeah, I can recompile my UNIX kernel to do the same. Blast Gert, there ARE net.people who still have machines that cannot handle 32-bit pointers! [ stty sarcastic ] But then again, those people usually don't have to shadow! :-) [ stty -sarcastic ] Fred.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (04/26/91)
If you increase the buffer cache size, you must recompile FS *AND* the kernel (due to a new maximum length of io-vectors passed to the drivers). C.v.W>