On 3/20/24 7:02 PM, Johannes Weiner wrote: > Page isolation currently sets MIGRATE_ISOLATE on a block, then drops > zone->lock and scans the block for straddling buddies to split > up. Because this happens non-atomically wrt the page allocator, it's > possible for allocations to get a buddy whose first block is a regular > pcp migratetype but whose tail is isolated. This means that in certain > cases memory can still be allocated after isolation. It will also > trigger the freelist type hygiene warnings in subsequent patches. > > start_isolate_page_range() > isolate_single_pageblock() > set_migratetype_isolate(tail) > lock zone->lock > move_freepages_block(tail) // nop > set_pageblock_migratetype(tail) > unlock zone->lock > __rmqueue_smallest() > del_page_from_freelist(head) > expand(head, head_mt) > WARN(head_mt != tail_mt) > start_pfn = ALIGN_DOWN(MAX_ORDER_NR_PAGES) > for (pfn = start_pfn, pfn < end_pfn) > if (PageBuddy()) > split_free_page(head) > > Introduce a variant of move_freepages_block() provided by the > allocator specifically for page isolation; it moves free pages, > converts the block, and handles the splitting of straddling buddies > while holding zone->lock. > > The allocator knows that pageblocks and buddies are always naturally > aligned, which means that buddies can only straddle blocks if they're > actually >pageblock_order. This means the search-and-split part can be > simplified compared to what page isolation used to do. > > Also tighten up the page isolation code around the expectations of > which pages can be large, and how they are freed. > > Based on extensive discussions with and invaluable input from Zi Yan. > > Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx> Nice cleanup of hairy code as well! Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
