Re: [RFC PATCH 05/26] mm: page_alloc: per-migratetype pcplist for THPs

[Mel Gorman]

On Tue, Apr 18, 2023 at 03:12:52PM -0400, Johannes Weiner wrote:
> Right now, there is only one pcplist for THP allocations. However,
> while most THPs are movable, the huge zero page is not. This means a
> movable THP allocation can grab an unmovable block from the pcplist,
> and a subsequent THP split, partial free, and reallocation of the
> remainder will mix movable and unmovable pages in the block.
> 
> While this isn't a huge source of block pollution in practice, it
> happens often enough to trigger debug warnings fairly quickly under
> load. In the interest of tightening up pageblock hygiene, make the THP
> pcplists fully migratetype-aware, just like the lower order ones.
> 
> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>

Split out :P

Take special care of this one because, while I didn't check this, I
suspect it'll push the PCP structure size into the next cache line and
increase overhead.

The changelog makes it unclear why exactly this happens or why the
patch fixes it. The huge zero page strips GFP_MOVABLE (so unmovable)
but at allocation time, it doesn't really matter what the movable type
is because it's a full pageblock. It doesn't appear to be a hazard until
the split happens. Assuming that's the case, it should be ok to always
set the pageblock movable for THP allocations regardless of GFP flags at
allocation time or else set the pageblock MOVABLE at THP split (always
MOVABLE at allocation time makes more sense).

-- 
Mel Gorman
SUSE Labs