Re: [PATCH mm-unstable 8/8] mm/hugetlb: convert demote_free_huge_page to folios

[John Hubbard <jhubbard@nvidia.com>]

On 1/9/23 10:23, Mike Kravetz wrote:
>>>>> No problems with the code, but I am not in love with the name subfolio.
>>>>> I know it is patterned after 'subpage'.  For better or worse, the term
>>>>> subpage is used throughout the kernel.  This would be the first usage of
>>>>> the term 'subfolio'.
>>>>>
>>>>> Matthew do you have any comments on the naming?  It is local to hugetlb,
>>>>> but I would hate to see use of the term subfolio based on its introduction
>>>>> here.
>>>>
>>>> I'm really not a fan of it either.  I intended to dive into this patch
>>>> and understand the function it's modifying, in the hopes of suggesting
>>>> a better name and/or method.
>>>
>>> At a high level, this routine is splitting a very large folio (1G for
>>> example) into multiple large folios of a smaller size (512 2M folios for
>>> example).  The loop is iterating through the very large folio at
>>> increments of the smaller large folio.  subfolio (previously subpage) is
>>> used to point to the smaller large folio within the loop.
>>>
>> If folio does not need to be part of the variable name, how about something
>> like 'demote_target'? The prep call inside the loop would then look like:
>>
>> prep_new_hugetlb_folio(target_hstate, demote_target, nid);
>>
>> so it is still clear that demote_target is a folio. A more concise version
>> could also be 'demote_dst' but that seems more ambiguous than target.
> 
> I am OK with that naming.  Primary concern was the introduction of the
> term subfolio.

How about one of these:

     smaller_folio
     inner_folio

Those are more self-explanatory, while still avoiding "subfolio".

thanks,
-- 
John Hubbard
NVIDIA