Re: [RFC PATCH 2/5] mm/page_alloc: count a merged buddy's pages under the merged type

[Rik van Riel <riel@surriel.com>]

On Wed, 2026-10-14 at 19:46 +0530, Dev Jain wrote:
> 
> 
> > +++ b/mm/page_alloc.c
> > @@ -993,6 +993,11 @@ static inline void __free_one_page(struct page
> > *page,
> >  			account_freepages(zone, 1 << order,
> > migratetype);
> >  		} else {
> >  			__del_page_from_free_list(buddy, zone,
> > order, buddy_mt);
> > +			/* The buddy's free pages join the merged
> > block's type. */
> > +			if (unlikely(buddy_mt != migratetype)) {
> > +				account_freepages(zone, -(1 <<
> > order), buddy_mt);
> > +				account_freepages(zone, 1 <<
> > order, migratetype);
> > +			}
> >  		}
> >  
> 
> MAX_PAGE_ORDER > pageblock_order confuses things so much : (

I'm not a fan, either. It trips me up every time.

> 
> Sashiko raises something:
> https://sashiko.dev/#/patchset/20261007021250.1665929-1-riel%40surriel.com
> 
> Although feels like it is exaggerating.

I suppose if we switch the two lines around, doing
the increment on migratetype before decrementing
buddy_mt we could avoid that transient underflow?

> 
> My concern is for systems with a high diff between MAX_PAGE_ORDER and
> pageblock_order. So on arm64 systems with 64K pagesize but pageblock
> size as 2M (and PMD size 512M), the pageblock order is 5. We use this
> configuration to reliably get TLB optimization from contpte size
> mappings.
> 
> Will we then repeatedly overflow the pcpu counter into the zone
> counter,
> regressing stuff?

The per_cpu_pages struct does not seem to keep
counts on a per migratetype basis at all. It
has per migratetype lists, but only one
pcp->count.

Also doesn't the pcp only carry order zero
pages currently?

I don't really understand your worry.

> 
> Perhaps I am overthinking. Your approach is clean, but perhaps we
> could
> also do:
> 
> void account_freepages_move(zone, order, buddy_mt, mt)
> 
> 	/* PCP-types do not have per-migratetype free counts. */
> 	if (likely (buddy_mt < MIGRATE_PCPTYPES && mt <
> MIGRATE_PCPTYPES))
> 		return;

Wouldn't that throw off the counts when we merge
e.g. a MIGRATE_UNMOVABLE page with a MIGRATE_MOVABLE
buddy?

With your test we would only ever do the free count
adjustment for mismatched types if one of the pages
was HIGHATOMIC or CMA. That leaves the common case
without coverage.

-- 
All Rights Reversed.