Re: page type is 3, passed migratetype is 1 (nr=512)

[Johannes Weiner <hannes@cmpxchg.org>]

Thanks for the config, I was able to reproduce it with.

On Tue, May 28, 2024 at 12:48:05PM -0400, Johannes Weiner wrote:
> Ah, but there DOES seem to be an issue with how we reserve
> highatomics: reserving and unreserving happens one pageblock at a
> time, but MAX_ORDER is usually bigger. If we rmqueue() an order-10
> request, reserve_highatomic_block() will only convert the first
> order-9 block in it; the tail will remain the original type, which
> will produce a buddy of mixed type blocks upon freeing.
> 
> This doesn't fully explain the warning here. We'd expect to see it the
> other way round - passing an assumed type of 3 (HIGHATOMIC) for the
> remainder that is actually 1 (MOVABLE). But the pageblock-based
> reservations look fishy. I'll cook up a patch to make this
> range-based. It might just fix it in a way I'm not seeing just yet.

tl;dr: With some debugging printks, I was able to see the
issue. Should be a straight-forward fix.

No order-10 allocations are necessary. Instead, smaller allocations
grab blocks for the highatomic pool. Unreserving is lazy, so as those
allocations get freed, they have a chance to merge together. Two
adjacent highatomic blocks can merge (MAX_ORDER > pageblock_order). On
unreserve, we now have an order-10 highatomic buddy, but only clear
the type on the first order-9 pageblock. A subsequent alloc + expand
will warn about this type inconsistency.

[  411.188518] UNRESERVE: pfn=26000 order=10
[  411.188739] ------------[ cut here ]------------
[  411.188881] 26200: page type is 3, passed migratetype is 1 (nr=512)
[  411.189097] WARNING: CPU: 1 PID: 10152 at mm/page_alloc.c:645 expand+0x1c8/0x1f0

I have a draft patch to make the highatomic reservations update all
blocks inside the range, not just the first one. I'll send it out as
soon as I have tested it properly.

Thanks