Re: NUMA policy issues with ZONE_MOVABLE

Lee Schermerhorn
2007-07-25T14:27:01Z

On Tue, 2007-07-24 at 21:20 -0700, Christoph Lameter wrote:
> The outcome of the 2.6.23 merge was surprising. No antifrag but only
> ZONE_MOVABLE. ZONE_MOVABLE is the highest zone.
>
> For the NUMA layer this has some weird consequences if ZONE_MOVABLE is populated
>
> 1. It is the highest zone.
>
> 2. Thus policy_zone == ZONE_MOVABLE
>
> ZONE_MOVABLE contains only movable allocs by default. That is anonymous
> pages and page cache pages?
>
> The NUMA layer only supports NUMA policies for the highest zone.
> Thus NUMA policies can control anonymous pages and the page cache pages
> allocated from ZONE_MOVABLE.
>
> However, NUMA policies will no longer affect non pagecache and non
> anonymous allocations. So policies can no longer redirect slab allocations
> and huge page allocations (unless huge page allocations are moved to
> ZONE_MOVABLE). And there are likely other allocations that are not
> movable.
>
> If ZONE_MOVABLE is off then things should be working as normal.
>
> Doesnt this mean that ZONE_MOVABLE is incompatible with CONFIG_NUMA?
>
>
> The mobility approach used subcategories of a zone which would have
> allowed the application of memory policies.

Isn't ZONE_MOVABLE always a subset of the memory in the highest "real"
zone--the one that WOULD be policy_zone if ZONE_MOVABLE weren't
configured? If so, perhaps we could just not assign ZONE_MOVABLE to
policy_zone in check_highest zone. We already check for >= or <
policy_zone where it's checked [zonelist_policy() and vma_migratable()],
so ZONE_MOVABLE will get a free pass if we clip policy_zone at the
highest !MOVABLE zone.

Lee