The suggestion here basically boils down to this: if the system could act on hints that somebody will be doing sequential access, then it should be more timid about caching for that file access. That is to say, it should allow that file to "use up" a smaller number of blocks from the cache (yes, the VM) at a time, and it should favor, if anything, a LIFO scheme instead of the usual FIFO (LRU) scheme. (That is to say, for the special case of *sequential* access, LRU == FIFO, and yet LIFO is probably more optimal for this case, at least if the file will be re-read later.)
Caching will do more good on files that that will be randomly accessed; an intermediate amount of good on files sequentially accessed but rewound and/or accessed over and over, and if the file system could somehow know (or be hinted) that the file is being sequentially accessed and is unlikely to be accessed again for a good long while it would clearly be better off not caching it at all. Of course the trick here is waving my hands and saying "assume that you know how the file will be accessed in the future." You ought to pillory me for *that* bit. Even with hinting there are problems with this whole idea. Still with some hinting the algorithm could probably be a little more clever. (Actually, Terry Lambert *did* pillory me for that bit, just a bit, when he pointed out the impossibility of knowing whether the file is being used in the same way by other processes.) And . . . also to Terry, yes, I know that my proposal about over-simplifies, but the point is that for sequential access you want to go "gentle" on making the cache of other process' and earlier reads go away. On Monday 27 January 2003 12:44 am, Tim Kientzle wrote: | Brian T. Schellenberger wrote: | > This to me is imminently sensible. | > In fact there seem like two rules that have come up in this | > discussion: | > | > 1. For sequential access, you should be very hesitant to throw away | > *another* processes blocks, at least once you have used more than, | > say, 25% of the cache or potential cache. | > | > 2. For sequential access, you should stop caching before you throw | > away your own blocks. If it's sequential it is, it seems to me, | > always a lose to throw away your *own* processes older bllocks on | > thee same file. | | The question isn't "should I throw away blocks or not?". | Obviously, the ideal is to keep everything in the cache, but | that's not possible. | | The question is "what blocks should be discarded?" You've | ruled out quite a few possibilities here. What blocks _should_ | be discarded? | | Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
