On 6 Dec 2024, at 4:59, David Hildenbrand wrote: > Let's special-case for the common scenarios that: > > (a) We are freeing pages <= pageblock_order > (b) We are freeing a page <= MAX_PAGE_ORDER and all pageblocks match > (especially, no mixture of isolated and non-isolated pageblocks) > > When we encounter a > MAX_PAGE_ORDER page, it can only come from > alloc_contig_range(), and we can process MAX_PAGE_ORDER chunks. > > When we encounter a >pageblock_order <= MAX_PAGE_ORDER page, > check whether all pageblocks match, and if so (common case), don't > split them up just for the buddy to merge them back. > > This makes sure that when we free MAX_PAGE_ORDER chunks to the buddy, > for example during system startups, memory onlining, or when isolating > consecutive pageblocks via alloc_contig_range()/memory offlining, that > we don't unnecessarily split up what we'll immediately merge again, > because the migratetypes match. > > Rename split_large_buddy() to __free_one_page_maybe_split(), to make it > clearer what's happening, and handle in it only natural buddy orders, > not the alloc_contig_range(__GFP_COMP) special case: handle that in > free_one_page() only. > > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> > --- > mm/page_alloc.c | 71 +++++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 57 insertions(+), 14 deletions(-) > LGTM. Reviewed-by: Zi Yan <ziy@xxxxxxxxxx> Best Regards, Yan, Zi
