Re: [PATCH v2 02/13] mm/page_alloc: some renames to clarify alloc_flags scopes

["Brendan Jackman" <brendan.jackman@linux.dev>]

On Wed Jun 24, 2026 at 3:03 PM UTC, Suren Baghdasaryan wrote:
> On Mon, Jun 22, 2026 at 3:01 AM Brendan Jackman <jackmanb@google.com> wrote:
>>
>> It's pretty confusing that:
>>
>> - The slowpath and fastpath have a totally distinct set of alloc_flags.
>>
>> - gfp_to_alloc_flags() sounds generic but it only influences the
>>   slowpath.
>>
>> - prepare_alloc_pages() is generic in that it sets up the
>>   alloc_context, but the alloc_flags it generates are only used for the
>>   fastpath.
>
> I understand you want to clarify the usage but this particular point
> seems to be an implementation detail. IOW, if tomorrow
> __alloc_frozen_pages_noprof() is changed to use alloc_flags when
> calling __alloc_pages_slowpath(), would we be renaming it back? So, I
> would suggest keeping alloc_flags as is in prepare_alloc_pages() 

I would say yes, we should rename it even though it might mean having to
rename it back later. IMO it's very useful to make it clear to the
reader that they also need to look elsewhere to find the slowpath flag
logic, without them having to notice this rather odd detail of
__alloc_frozen_pages_noprof().

But, yeah I guess prepare_alloc_pages() doesn't really care that its
caller is only using the result for the fastpath so I could see the
rationale for keeping the arg as alloc_flags...

> and its callers. 

...  but for it's caller I really do think the rename is necessary and
doesn't really have any downside? Especially once alloc_context gets an
alloc_flags field as it does later in the series.

> The rest LGTM.

Thanks as always, I appreciate the review.