Date: Sun, 26 Jan 2003 17:28:49 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Sean Hamilton <sh@bel.bc.ca>, hackers@FreeBSD.ORG Subject: Re: Random disk cache expiry Message-ID: <3E348B51.6F4D6096@mindspring.com> References: <000501c2c4dd$f43ed450$16e306cf@slugabed.org> <200301261931.h0QJVCp8052101@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > Hi Sean. I've wanted to have a random-disk-cache-expiration feature > for a long time. We do not have one now. We do have mechanisms in > place to reduce the impact of sequential cycling a large dataset so > it does not totally destroy unrelated cached data. I really dislike the idea of random expiration; I don't understand the point, unless you are trying to get better numbers on some benchmark that intentionally determines the cache size, and then chooses to use a dataset larger than that, to factor out caching and/or make bogus representations about the value of caching in the first place. There are a number of well-known proxy cache benchmarks that do this, because the person who wrote them wanted to advocate against the use of proxy caches entirely. A number of proxy cache vendors use random page replacement to get around the benchmark tuning itself to get the worst possible performance when using a proxy cache; with random replacement, you maintain 25% of your workingselt, instead of 0% with intentional overflow from the benchmark (or 100%, if you are not doing bogus things to try and advocate against cahe vendors). > Due to the way our page queues work, it's not an easy problem to solve. It's actually pretty trivial, if you are willing to do it on a per-vnode basis, rather than a per-open instance basis. This is called a "working set quota" on VMS, and the code to do this has been around there for over 20 years now. The way you do this is to keep a count of pages associated with a given vnode, and if you are over the quota, and want more pages, to steal from the end of the per-vnode LRU, rather than going to a system wide LRU, and competing with other files. This assumes that you are not ignoring the value of locality of reference, and hacking the code to make some bogus benghmark run faster, and are instead replacing pages for performance reasons -- real performance reasons, not fake ones. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E348B51.6F4D6096>