Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!ira.uka.de!iravcl!guenther From: SCHREINER@iravcl.ira.uka.de (Guenther Schreiner) Newsgroups: comp.os.minix Subject: Re: Increasing buffersize causes real problems Message-ID: <90.179.12:00:44@ira.uka.de> Date: 28 Jun 90 10:16:00 GMT References: <1865@runxtsa.runx.oz.au> Sender: news@ira.uka.de (USENET News System) Reply-To: Guenther Schreiner Organization: University of Karlsruhe, FRG Lines: 20 In article <1865@runxtsa.runx.oz.au> brucee@runxtsa.runx.oz.au (Bruce Evans) writes: >Minix-386 uses NR_BUFS = 320 and NR_BUF_HASH = 512. I think a much smaller >number of hash entries will work, but hash entries are cheap compared with >buffers, so I used more. I think about 25% of memory should be used for >buffers and 0% for a RAM disk, except a floppy-only system needs a RAM disk >(assuming the number of buffers is not limited by the address space as on a >PC). > >Recompiling the kernel (just misc.c, and floppy.c on the PC) is important. >The memory for the I/O vector(s) is a bit extravagant for a large number of >buffers. The vector copying should be rewritten some day. If i do this on my 2 MB ATARI-ST with the given values the system isn't able to boot. I got a message like 'unable to report size to mm'. I must reduce the values to something like NR_BUFS = 100 NR_BUF_HASH = 64 to get it running. Perhaps this comes from the 16 bit ST MINIX int's - MINIX-386 (Bruce ?) uses 32 bit i believe. Ralf Wenk, using a friends account