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
