On 1/9/23 2:01 PM, John Hubbard wrote:
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".
I would be fine with inner_folio.
Thanks,
Sidhartha Kumar
thanks,
