[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090223143232.GJ6740@csn.ul.ie>
Date: Mon, 23 Feb 2009 14:32:32 +0000
From: Mel Gorman <mel@....ul.ie>
To: Andi Kleen <andi@...stfloor.org>
Cc: Linux Memory Management List <linux-mm@...ck.org>,
Pekka Enberg <penberg@...helsinki.fi>,
Rik van Riel <riel@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Christoph Lameter <cl@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
Nick Piggin <npiggin@...e.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lin Ming <ming.m.lin@...el.com>,
Zhang Yanmin <yanmin_zhang@...ux.intel.com>
Subject: Re: [RFC PATCH 00/20] Cleanup and optimise the page allocator
On Mon, Feb 23, 2009 at 01:02:59AM +0100, Andi Kleen wrote:
> Mel Gorman <mel@....ul.ie> writes:
>
>
> BTW one additional tuning opportunity would be to change cpusets to
> always precompute zonelists out of line and then avoid doing
> all these checks in the fast path.
>
hmm, it would be ideal but I haven't looked too closely at how it could
be implemented. I thought first you could just associate a zonelist with
the cpuset but you'd need one for each node allowed by the cpuset so it
could get quite large. Then again, it might be worthwhile if cpusets
were expected to be very long lived.
If there are any users of cpusets watching, would you be interested in
profiling with cpusets enabled and see how much time we spend in that
code?
--
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