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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
