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

[Vlastimil Babka (SUSE)]

On 6/24/26 18:13, Brendan Jackman wrote:
> 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@xxxxxxxxxx> 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.

I don't mind either of the renames. It's all page_alloc.c internal anyway.

>> The rest LGTM.
> 
> Thanks as always, I appreciate the review.