jack@vu44.UUCP (Jack Jansen) (10/04/84)
I heard a rumour that someone in unix-land had hacked the buffer allocation routines so that reading a large program doesn't effectively flush your buffer cache, which is what happens in a normal V7 (the oldest block is allocated every time something is needed, so reading something big results in all your useful buffers being re-used). I think it had something to do with readahead buffers being allocated in a different way from norma buffers. Is there anyone out there who knows of such a mod? Please send me mail if you have it, or know of someone who does. Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack or ...!vu44!htsa!jack
rpw3@redwood.UUCP (Rob Warnock) (10/05/84)
+--------------- | I heard a rumour that someone in unix-land had hacked the | buffer allocation routines so that reading a large program | doesn't effectively flush your buffer cache... +--------------- True. This policy is implemented in the Fortune Systems 32:16's version of UNIX, called FOR:PRO, which has a (nearly) V7 filesystem (but with 1024 byte blocks). +--------------- | ...in a normal V7 (the oldest block is allocated every time something | is needed, so reading something big results in all your useful | buffers being re-used). I think it had something to do with | readahead buffers being allocated in a different way from normal buffers. +--------------- Close. The actually policy is: When releasing a just-read block to the free list (after the copy to the user is done), if you see that the block was read-ahead [past tense: "RED-ahed"] (that is, caused to be read not directly by the user but by the read-ahead strategy in the filesystem), release the block to the FRONT of the free list, not the end. This causes long sequential reads to flip back and forth using the first two blocks of the free list, leaving the others alone. This applies to ALL sequentially- read files, not just programs. (Incidentally, the first two blocks of a sequential file will stay in the cache. Exercise for the reader: Why TWO?) This is very useful in small v7-style systems with relatively slow access-time disks (such as stepper-motor-poistioner winchesters), although the usefulness in other, larger systems is not known. Do not blindly expect it to improve OR harm things in your configuration. It seems mostly useful in multi-user systems with a lot of "database"-style activity, such as business applications and word-processing, where many directory traversals occur. It can actually decrease slightly the performance of a single-user system, since even trivial programs must be re-read from disk (unless they are 2K or less!). On the other hand, in an environment where many of the "programs" are small shell scripts, things may get better (especially if you "sticky-text" the shell). Since the strategy is implemented at the block-driver level (roughly), even long directories will fail to have their higher blocks cached (although, from above, blocks 0 & 1 WILL be). Whether this is good or bad depends on your configuration. This policy was suggested by yours truly, implemented by Rick Kiessig, and reviewed, discussed, and criticized by Dave Yost, John Bass, Bakul Shah, and others. (None of those mentioned are currently with Fortune Systems, though.) Rob Warnock UUCP: {ihnp4,ucbvax!amd}!fortune!redwood!rpw3 DDD: (415)572-2607 (*new*) Envoy: rob.warnock/kingfisher USPS: 510 Trinidad Ln, Foster City, CA 94404 (*new*)