"Brian T. Schellenberger" wrote: > 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.
You can not have a block in a vm object which is not a cached copy of a data block in the backing store object. You can not access data blocks from the disk, except in the context of a backing store object. FreeBSD has a unified VM and buffer cache. FreeBSD does not copy data off the disk into a buffer, and then decide whether to copy the buffer/reference it from a cache: if it is in a buffer, it's in the cache, period. You are talking about avoiding a copy that doesn't happen. The real issue is whether, after notification of completion of the transfer (via wakeup of the blocked "read" system call), the VM buffer in question is relinked to the other end of the LRU list, artificially "aging" it. The answer to this is that you can't do it, because you do not know that the file system access itself is sequential for all people who have the file open at the time you make the request, and you can't know to which buffers you are actually referring, because this is handled via demand paging, "under the covers", and therefore not visible to the "read" call at that level. > These algorithmic changes seem to me to be more likely to be optimal > most of the time. No. All openers get different struct file's, but they get the same vp, which means they get the same vm_object_t. > A random approach *does* reduce the penalty for worst-case scenarios but > at the cost of reducing the benefit of both "normal" and "best-case" > scenarios, it seems to me, even more. I believe the "random page replacement" alrgotihm that was being referred to here is actually only supposed to be triggered if the file access has been advised tbe sequential; even so, there is no win in doing this, as you say (see other posting). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
