Peter Zijlstra wrote: > > 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. > > > > Certainly this should be a configurable option and kernel's behavior > > should not be changed in general. > > Ah, this would be a clear case of the page reclaim selecting the wrong > working set.
Yes. > It is perfectly fine for a page cache page to evict a app page (be it > anon or not) if that page cache page is used more frequently than the > app page in question. It seems, that there is currently a clear preference for pagecache-page over app-page. Some form of prio-selection could probably aid the situation. > Trouble seems to be that the current algorithm gets it quite wrong at > times. It breaks down when memory gets tight. You can actually hear it thrashing the disk, although it's not supposed to thrash, even with swapoff. > Also stating that free memory somehow is good for you is weird, free > memory is a loss, you under utilise your machine. Keeping clean > pagecache pages in there that are likely to be referenced again is a > clear win; it saves the tediously slow load from disk. That's the theory. > So you're now proposing to limit the page cache As a workaround. > where as its clear that > the better solution would be to tune replacement policy Yes. Hopefully successfully. > (and or provide > hints to said mechanism using madvise/fadvise) Not feasible; source is sometimes not immediately available. 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/
