Re: [RFC PATCH 00/20] Cleanup and optimise the page allocator

[Mel Gorman <mel@csn.ul.ie>]

On Mon, Feb 23, 2009 at 06:49:48PM +0100, Andi Kleen wrote:
> > 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
> 
> Yes like that. This was actually discussed during the initial cpuset
> implementation. I thought back then it would be better to do it
> elsewhere, but changed my mind later when I saw the impact on the
> fast path.
> 

Back then there would have been other anomolies as well such as
MPOL_BIND using zones in the wrong order. Zeroing would still have
dominated the cost of the allocation and slab would hide other details.
Hindsight is 20/20 and all that.

Right now, I don't think cpusets are a dominant factor for most setups but
I'm open to being convinced otherwise. For now, I'm happy if it's just shoved
a bit more to the side in the non-cpuset case. Like the CPU cache hot/cold
path, it might be best to leave it for a second or third pass and tackle
the low-lying fruit for the first pass.

> > 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
> 
> Yes you would need one per node, but that's not a big problem because
> systems with lots of nodes are also expected to have lots of memory.
> Most systems have a very small number of nodes.
> 

That's a fair point on the memory consumption. There might be issues
with the cache consumption but if the cpuset is being heavily used for an
allocation-intensive workload then it probably will not be noticeable.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab