[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101118092812.GF8135@csn.ul.ie>
Date: Thu, 18 Nov 2010 09:28:12 +0000
From: Mel Gorman <mel@....ul.ie>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc: Andrea Arcangeli <aarcange@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/8] mm: compaction: Use the LRU to get a hint on where
compaction should start
On Thu, Nov 18, 2010 at 06:10:48PM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 17 Nov 2010 16:22:48 +0000
> Mel Gorman <mel@....ul.ie> wrote:
>
> > The end of the LRU stores the oldest known page. Compaction on the other
> > hand always starts scanning from the start of the zone. This patch uses
> > the LRU to hint to compaction where it should start scanning from. This
> > means that compaction will at least start with some old pages reducing
> > the impact on running processes and reducing the amount of scanning. The
> > check it makes is racy as the LRU lock is not taken but it should be
> > harmless as we are not manipulating the lists without the lock.
> >
> > Signed-off-by: Mel Gorman <mel@....ul.ie>
>
> Hmm, does this patch make a noticable difference ?
To scanning rates - yes.
> Isn't it better to start scan from the biggest free chunk in a zone ?
>
Not necessarily. The biggest free chunk does not necessarily contain old
pages so one could stall a process by migrating a very active page. The same
applies for selecting the pageblock with the oldest LRU page of course but
it is less likely.
I prototyped a a patch that constantly used the buddy lists to select the
next pageblock to migrate from. The problem was that it was possible for it
to infinite loop because it could migrate from the same block more than once
in a migration cycle. To resolve that, I'd have to keep track of visited
pageblocks but I didn't want to require additional memory unless it was
absolutly necessary. I think the concept can be perfected and its impact
would be a reduction of scanning rates but it's not something that is
anywhere near merging yet.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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