Messages in this thread | | | Date | Wed, 27 Mar 2024 09:06:33 +0100 | Subject | Re: [PATCH 09/10] mm: page_isolation: prepare for hygienic freelists | From | Vlastimil Babka <> |
| |
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@cmpxchg.org>
Nice cleanup of hairy code as well!
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
| |