[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DA3DFB9C-960D-451B-866C-E5B8A9B3ABB8@nvidia.com>
Date: Mon, 02 Dec 2024 13:33:42 -0500
From: Zi Yan <ziy@...dia.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linuxppc-dev@...ts.ozlabs.org, Andrew Morton <akpm@...ux-foundation.org>,
Oscar Salvador <osalvador@...e.de>, Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Naveen N Rao <naveen@...nel.org>, Madhavan Srinivasan <maddy@...ux.ibm.com>
Subject: Re: [PATCH v1 5/6] mm/page_alloc: forward the gfp flags from
alloc_contig_range() to post_alloc_hook()
On 2 Dec 2024, at 7:58, David Hildenbrand wrote:
> In the __GFP_CONT case, we already pass the gfp_flags to
s/__GFP_CONT/__GFP_COMP/
> prep_new_page()->post_alloc_hook(). However, in the !__GFP_CONT case, we
Ditto
> essentially pass only hardcoded __GFP_MOVABLE to post_alloc_hook(),
> preventing some action modifiers from being effective..
>
> Let's pass our now properly adjusted gfp flags there as well.
>
> This way, we can now support __GFP_ZERO for alloc_contig_*().
>
> As a side effect, we now also support __GFP_SKIP_ZERO and__GFP_ZEROTAGS;
> but we'll keep the more special stuff (KASAN, NOLOCKDEP) disabled for
> now.
>
> It's worth nothing that with __GFP_ZERO, we might unnecessarily zero pages
s/nothing/noting/
> when we have to release part of our range using free_contig_range() again.
> This can be optimized in the future, if ever required; the caller we'll
> be converting (powernv/memtrace) next won't trigger this.
>
> Signed-off-by: David Hildenbrand <david@...hat.com>
> ---
> mm/page_alloc.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
After the commit log is fixed, Reviewed-by: Zi Yan <ziy@...dia.com>
Best Regards,
Yan, Zi
Powered by blists - more mailing lists