Thus spake Fergal Daly <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (Tim Kientzle) wrote in message > news:<b128ta$b0n$[EMAIL PROTECTED]>... > > Personally, I think there's a lot of merit to _trying_ > > There's even more merit in only pretending to try...
Welcome to my quotes file. > As you can see, the locking cache is always better than the random one and the > file doesn't have to be very big for it to be hugely better. You have found an optimal replacement algorithm for the case of repeated sequential reads. In fact, if you know in advance what the access pattern is going to be, it is *always* possible to find an optimal replacement algorithm. Specifically, you always replace the block in the cache that will not be used for the longest time in the future. If you want the system to always cache the right thing in the general case, the only hint you would need to provide the system is a reference string specifying the predicted access pattern. (If I were to do this, my first reaction would be to encode it as an FSA.) If that proves to be infeasible, I'm sure there are ways to approximate the same thing. The hard parts, I think, would be teaching the VM system to use the new information, and gathering statistics from which you form your hints. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
