Re: NUMA policy issues with ZONE_MOVABLE

Christoph Lameter
2007-07-27T18:38:25Z

On Fri, 27 Jul 2007, Mel Gorman wrote:

> Initial tests imply yes but I haven't done broader tests yet. It saves 64
> bytes on the size of the node structure on a non-numa i386 machine so even
> that might be noticable in some cases.

I think you can minimize the impact further by encoding information you
are looking for in the zone pointer. We are scanning for zones and for
node numbers. The zones require up to 2 bits and the nodes up to 10 bits.
So if we page align the zones structure then we have enough bits to encode
the information we are looking for in the pointers. Thus saving us
dereferencing it to check.

This may even be a performance increase vs the current situation.

> > I think this should_filter() creates more overhead than which it saves.
>
> It's why part of the patch adds a zone_idx field to struct zone instead
> of mucking around with pgdat->node_zones.

See above. Avoid cacheline fetch by using the low bits of the zone pointer
for zone_idx.

> > Isnt there some way to fold these traversals into a common page allocator
> > function?
>
> Probably. When I looked first, each of the users were traversing the zonelist
> slightly differently so it wasn't obvious how to have a single iterator but
> it's a point for improvement.

I wrote most of those and I'd be glad if you could consolidate the code
somehow.