----- Original Message ----- From: "Tim Kientzle" <[EMAIL PROTECTED]> | Cycling through large data sets is not really that uncommon. | I do something like the following pretty regularly: | find /usr/src -type f | xargs grep function_name | | Even scanning through a large dataset once can really hurt | competing applications on the same machine by flushing | their data from the cache for no gain. I think this | is where randomized expiration might really win, by reducing the | penalty for disk-cache-friendly applications who are competing | with disk-cache-unfriendly applications.
In my case I have a webserver serving up a few dozen files of about 10 MB each. While yes it is true that I could purchase more memory, and I could purchase more drives and stripe them, I am more interested in the fact that this server is constantly grinding away because it has found a weakness in the caching algorithm. After further thought, I propose something much simpler: when the kernel is hinted that access will be sequential, it should stop caching when there is little cache space available, instead of throwing away old blocks, or be much more hesitant to throw away old blocks. Consider that in almost all cases where access is sequential, as reading continues, the chances of the read being aborted increase: ie, users downloading files, directory tree traversal, etc. Since the likelihood of the first byte reading the first byte is very high, and the next one less high, and the next less yet, etc, it seems to make sense to tune the caching algorithm to accomodate this. While discussing disks, I have a minor complaint: at least on IDE systems, when doing something like an untar, the entire system is painfully unresponsive, even though CPU load is low. I presume this is because when an executable is run, it needs to sit and wait for the disk. Wouldn't it make sense to give very high disk priority to executables? Isn't that worth the extra seeks? sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
