Re: [RFC] Limit the size of the pagecache

[Al Boldi <a1426z@gawab.com>]

Vaidyanathan Srinivasan wrote:
> Al Boldi wrote:
> > Rik van Riel wrote:
> >> Christoph Lameter wrote:
> >>> This is a patch using some of Aubrey's work plugging it in what is
> >>> IMHO the right way. Feel free to improve on it. I have gotten
> >>> repeatedly requests to be able to limit the pagecache.
> >>
> >> IMHO it's a bad hack.
> >>
> >> It would be better to identify the problem this "feature" is
> >> trying to fix, and then fix the root cause.
> >
> > Ok, here is the problem:  kswapd.
> >
> > Limiting the page-cache memory inhibits invoking kswapd needlessly,
> > aiding performance and easing OOM pressures.
>
> 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.

Agreed 100%.  Thanks for expanding exactly what I meant.

> Certainly this should be a configurable option and kernel's behavior
> should not be changed in general.
>
> > I tried the patch; it works.
> >
> :)
> :
> > But it needs a bit of debugging.  Setting pagecache_ratio = 1 either
> > deadlocks or reduces thru-put to < 1mb/s.
>
> Yes, going below 5% on my 1GB RAM machine causes severe performance
> problems.  We need to hard wire a reasonable lower limit and not
> provide a noose for the end user to tie around!

One reason to test full range settings, is to expose underlying system 
problems, like scalability.  By limiting the range, you only hide a problem 
that was exposed.


Thanks!

--
Al

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