stevesc@microsoft.UUCP (Steve Schonberger) (12/08/89)
Is it possible to allow the filesystem process to use all (or most of) free memory as disk cache? (If it does that already, excuse the dumb question; it's been a long time since I read the code from The Book, and I've never seen the code from more recent versions.) It seems like something that could be done, and which would speed up the system a great deal. Of course, every time memory was allocated to a process it would first have to be taken away from the cache block pool, but if dirty blocks were one way or another kept out of the areas most likely to be claimed by new processes (such as by allocating cache blocks for files open for writing only in the fixed portion of the cache), taking blocks away from the cache would just be a matter of marking them as no longer cached. Such an addition would take quite a bit of work on the filesystem, and a little change to the memory manager (so that it would tell the filesystem to release them before it gave them to another process), and I think would be transparent elsewhere. Are there any obvious problems with this other than the need for someone to code it? Any more subtle problems? Has this been discussed before so that I'm just wasting bandwidth bringing it up again? -- Steve Schonberger microsoft!stevesc@uunet.uu.net "Working under pressure is the sugar that we crave" --A. Lamb
evans@ditsyda.oz (Bruce Evans) (12/11/89)
In article <9374@microsoft.UUCP> stevesc@microsoft.UUCP (Steve Schonberger) writes: >Is it possible to allow the filesystem process to use all (or most of) >free memory as disk cache? (If it does that already, excuse the dumb Everything is possible :-). This is a good idea. >Are there any obvious problems with this other than the need for >someone to code it? Any more subtle problems? Has this been It is a !@#@$# to code in C in small model without far pointers. The file system code depends on buffers being accessible with normal pointers. Much copying would be required. Direct copying by the file system task is taboo, and using a system call to copy takes 3 times as long. So a 3-layer cache (FS memory, "extended" memory, and disk) is probably required. The interaction with the memory manager will be messy. When space is wanted for a new process, FS may have to truncate the cache and rearrange it to get rid of holes. I think considerable copying to do the rearrangement would be worthwhile. Even now, it is easy to waste 100K due to fragmentation. The cache ought to compete with the RAM disk for memory too. The RAM disk should have some fixed size smaller than the memory size. Blocks on it not in files should not be be allocated. I'm not sure what the raw /dev/ram should do with non-allocated blocks. I have implemented about half these things on a 2 MHz 6809 system with 560K RAM and an MMU. The RAM disk competed with programs for memory. The cache size was fixed but could be varied using a system call. I/O was 2 to 4 times faster than Minix's on a 5MHz PC, and effectively more since the system wasn't disk bound (there was useful stuff in ROM and the C compiler and support were locked into RAM). I now have 32-bit mode working on a 386 so there is no 64K limit on pointers in FS. I use a 320K cache. Currently, FS is not allowed to access memory outside its data segment, and has no way to allocate such memory. The MMU will make many things easier at the cost of portability. -- Bruce Evans evans@ditsyda.oz.au
norsk@sequent.UUCP (Doug Thompson) (12/13/89)
In article <2350@ditsyda.oz> evans@ditsyda.oz (Bruce Evans) writes: >In article <9374@microsoft.UUCP> stevesc@microsoft.UUCP (Steve Schonberger) writes: >>Is it possible to allow the filesystem process to use all (or most of) >>free memory as disk cache? (If it does that already, excuse the dumb > >Everything is possible :-). This is a good idea. > > >I now have 32-bit mode working on a 386 so there is no 64K limit on pointers >in FS. I use a 320K cache. Currently, FS is not allowed to access memory >outside its data segment, and has no way to allocate such memory. The MMU >will make many things easier at the cost of portability. >-- >Bruce Evans evans@ditsyda.oz.au I was wondering Bruce, what are the future minix on a 32-bit 386 plans??? It will be great to get rid of the 16-bit limitations and have more memory. Is it only a research project or are there possible releases sometime in the future?? Whose C compiler?? Anyway, this is of interest. TIA (BTW - thanks for all the info you keep posting.) -- Douglas Thompson UUCP: ..{tektronix,ogicse,uunet}!sequent!norsk Sequent Computer Systems Phone: (503) 526-5727 15450 SW Koll Parkway !"The scientist builds to learn;the engineer learns in Beaverton OR 97006 !order to build." Fred Brooks