Re: ~500 megs cached yet 2.6.5 goes into swap hell

[Marc Singer <elf@buici.com>]

On Wed, Apr 28, 2004 at 08:19:24PM -0700, Andrew Morton wrote:
> Marc Singer <elf@buici.com> wrote:
> >
> > > That's what people have been asking for.  What are you suggesting should
> > > happen instead?
> > 
> > I'm thinking that the problem is that the page cache is greedier that
> > most people expect.  For example, if I could hold the page cache to be
> > under a specific size, then I could do some performance measurements.
> > E.g, compile kernel with a 768K page cache, 512K, 256K and 128K.  On a
> > machine with loads of RAM, where's the optimal page cache size?
> 
> Nope, there's no point in leaving free memory floating about when the
> kernel can and will reclaim clean pagecache on demand.

It could work differently from that.  For example, if we had 500M
total, we map 200M, then we do 400M of IO.  Perhaps we'd like to be
able to say that a 400M page cache is too big.  The problem isn't
about reclaiming pagecache it's about the cost of swapping pages back
in.  The page cache can tend to favor swapping mapped pages over
reclaiming it's own pages that are less likely to be used.  Of course,
it doesn't know that...which is the rub.

If I thought I had an method for doing this, I'd write code to try it
out.

> What you discuss above is just an implementation detail.  Forget it.  What
> are the requirements?  Thus far I've seen

The requirement is that we'd like to see pages aged more gracefully.
A mapped page that is used continuously for ten minutes and then left
to idle for 10 minutes is more valuable than an IO page that was read
once and then not used for ten minutes.  As the mapped page ages, it's
value decays.

> a) updatedb causes cache reclaim
> 
> b) updatedb causes swapout
> 
> c) prefer that openoffice/mozilla not get paged out when there's heavy
>    pagecache demand.
> 
> For a) we don't really have a solution.  Some have been proposed but they
> could have serious downsides.
> 
> For b) and c) we can tune the pageout-vs-cache reclaim tendency with
> /proc/sys/vm/swappiness, only nobody seems to know that.

I've read the source for where swappiness comes into play.  Yet I
cannot make a statement about what it means.  Can you?