Re: [RFC] Limit the size of the pagecache

[Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>]

Al Boldi wrote:
> 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.

Agreed.  This is a good point.

> 
> 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/
>