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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
