Re: Idea for improving linux buffer cache behaviour

[Helge Hafting <helgehaf@aitel.hist.no>]

On Sat, Oct 04, 2003 at 10:34:58PM -0700, Mike Fedyk wrote:
> On Sat, Oct 04, 2003 at 03:14:14PM -0400, Rik van Riel wrote:
> > On Sat, 4 Oct 2003, David Ashley wrote:
> > 
> > > Forgive me if this has already been thought of, or is obsolete, or is
> > > just plain a bad idea, but here it is:
> > 
> > Do you also want an answer if the kernel already does
> > exactly what you are suggesting ? ;)
> > 
> 
> Then why doesn't it work better?
> 
> > > 1) Lowest access count looked at first to toss
> > > 2) If access counts equal, throw out oldest first
> > 
> > > The net result is commonly used items you very much want to remain in
> > > cache always quickly get rated very highly as the system is used.
> > 
> > Which results in exactly the behaviour you're complaining
> > about ;))
> 
> So, you use the system, have glibc loaded, and then play a dvd, and now
> glibc needs to be re-read because it's not in cache.
> 
> Why wasn't glibc (one example) kept in cache with the streaming read from
> the dvd?

There may be many reasons here, take a look at how many times the
dvd contents were used.  You may get a surprise there.  
The number ought to be 1, right?  But the burner program may read
smaller chunks or something, causing many references to the same block.

Also, the number-of-references approach has its own problems.
Something that is used a lot for a while will stay in cache for
a long while when no longer used, taking up space.  That can be
a problem too - i.e. run some large simulation which fill up
memory for a while, and nothing else stays in cache afterwards.

Helge Hafting