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
