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