[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1169720945.6189.52.camel@twins>
Date: Thu, 25 Jan 2007 11:29:05 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
Cc: Al Boldi <a1426z@...ab.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Limit the size of the pagecache
> 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.
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.
Trouble seems to be that the current algorithm gets it quite wrong at
times.
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.
So you're now proposing to limit the page cache were as its clear that
the better solution would be to tune replacement policy (and or provide
hints to said mechanism using madvise/fadvise)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists