:I think you missed Matt's point, which is well-taken:
:
:Even if everybody accesses it sequentially, if you have 100 processes
:accessing it sequentially at the *same* time, then it would be to your
:benefit to leave the "old" pages around because even though *this*
:process won't access it again, the *next* process very well might, if
:it just happens to be reading it sequentially as well but is a little
:further behind on its sequential read.
Right, and if the same 100 processes are accessing N files sequentially
instead of just one, you get a different effect... you might blow out
your cache if the aggregate size of the N files is too large. But then
if some of those processes are accessing the same file, and other processes
were accessing different files, you might want to cache that file
but possibly not cache others, even though all the files are (for this
example) the same size. But then what if some of the processes accessing
some of those other files were from slow clients? You could get away
with not caching those files and then you might possibly be able cache
all the remaining files (being accessed by faster clients).
And so on, and so forth. It gets even more complicated when you throw
in read verses write verses read-modify-write accesses, and even more
complicated when you add other load factors (e.g. the sheer number of
connections might reduce the memory available for caching on the fly,
or trying to balance executable pages verses data pages to optimize
paging and program performance).
So there is no 'perfect' caching algorithm. There are simply too many
variables even in a well defined environment for even the best system
heuristics to cover optimally.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
