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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux