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/