Re: Idea for improving linux buffer cache behaviour

[CJ]

1. A problem is o_direct is broken and/or confused with
   file systems.  There is a misguided micro-optimization
   that requires page alignment and sector alignment and
   size.  Even if broken DMA or controllers require these,
   O_DIRECT need not.  O_DIRECT is about the cache.

2. Even when O_DIRECT requires a bounce buffer, it need
   not wipe memory, it could easily confine itself to 1-4
   buffers and even support read ahead.  Then DVDs could
   be mounted O_DIRECT by default.

3. Buffer management has become a DOS on Linux leaving
   disk bound programs with the disk light off for ten
   seconds at a crack.  Writing is worst of all.



Helge Hafting wrote:

> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> .

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/