Re: [RFC] Limit the size of the pagecache

[Al Boldi <a1426z@gawab.com>]

Peter Zijlstra wrote:
> > Apart from kswapd, limiting pagecache helps performance of
> > applications by not eating away their ANON pages or other parts of its
> > resident data set.  When there is enough free memory, then there is no
> > performance issue.  However memory is always utilized to the max.
> > Hence every pagecache page that is allocated should come from some
> > application's RSS, or from cold pagecache page.  If that page was
> > stolen from some application, then that application pays the price for
> > swapping or reading the page back to memory.  This scenario is what we
> >  want to avoid.  All that we are trying to achieve is that pagecache
> > eats a (unmapped) pagecache page and not steal memory from other
> > important application's resident set.
> >
> > Certainly this should be a configurable option and kernel's behavior
> > should not be changed in general.
>
> Ah, this would be a clear case of the page reclaim selecting the wrong
> working set.

Yes.

> It is perfectly fine for a page cache page to evict a app page (be it
> anon or not) if that page cache page is used more frequently than the
> app page in question.

It seems, that there is currently a clear preference for pagecache-page over 
app-page.  Some form of prio-selection could probably aid the situation.

> Trouble seems to be that the current algorithm gets it quite wrong at
> times.

It breaks down when memory gets tight.  You can actually hear it thrashing 
the disk, although it's not supposed to thrash, even with swapoff.

> Also stating that free memory somehow is good for you is weird, free
> memory is a loss, you under utilise your machine. Keeping clean
> pagecache pages in there that are likely to be referenced again is a
> clear win; it saves the tediously slow load from disk.

That's the theory.

> So you're now proposing to limit the page cache

As a workaround.

> where as its clear that
> the better solution would be to tune replacement policy

Yes.  Hopefully successfully.

> (and or provide
> hints to said mechanism using madvise/fadvise)

Not feasible; source is sometimes not immediately available.


Thanks!

--
Al