[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45E87D93.9000100@redhat.com>
Date: Fri, 02 Mar 2007 14:40:03 -0500
From: Rik van Riel <riel@...hat.com>
To: Christoph Lameter <clameter@...r.sgi.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@...net.ie>, npiggin@...e.de, mingo@...e.hu,
jschopp@...tin.ibm.com, arjan@...radead.org,
torvalds@...ux-foundation.org, mbligh@...igh.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: The performance and behaviour of the anti-fragmentation related
patches
Christoph Lameter wrote:
> On Fri, 2 Mar 2007, Rik van Riel wrote:
>
>> I would like to see separate pageout selection queues
>> for anonymous/tmpfs and page cache backed pages. That
>> way we can simply scan only that what we want to scan.
>>
>> There are several ways available to balance pressure
>> between both sets of lists.
>>
>> Splitting them out will also make it possible to do
>> proper use-once replacement for the page cache pages.
>> Ie. leaving the really active page cache pages on the
>> page cache active list, instead of deactivating them
>> because they're lower priority than anonymous pages.
>
> Well I would expect this to have marginal improvements and delay the
> inevitable for awhile until we have even bigger memory. If the app uses
> mmapped data areas then the problem is still there.
I suspect we would not need to treat mapped file backed memory any
different from page cache that's not mapped. After all, if we do
proper use-once accounting, the working set will be on the active
list and other cache will be flushed out the inactive list quickly.
Also, the IO cost for mmapped data areas is the same as the IO
cost for unmapped files, so there's no IO reason to treat them
differently, either.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
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