[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6B9E52F3-1893-4D0D-AC7A-BC1CA96F0247@nvidia.com>
Date: Fri, 06 Dec 2024 11:58:34 -0500
From: Zi Yan <ziy@...dia.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>, Vlastimil Babka <vbabka@...e.cz>,
Yu Zhao <yuzhao@...gle.com>
Subject: Re: [PATCH v1 1/2] mm/page_alloc: conditionally split >
pageblock_order pages in free_one_page() and move_freepages_block_isolate()
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@...hat.com>
> ---
> mm/page_alloc.c | 71 +++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 57 insertions(+), 14 deletions(-)
>
LGTM. Reviewed-by: Zi Yan <ziy@...dia.com>
Best Regards,
Yan, Zi
Powered by blists - more mailing lists