Messages in this thread | | | Date | Mon, 9 Jan 2023 12:01:45 -0800 | Subject | Re: [PATCH mm-unstable 8/8] mm/hugetlb: convert demote_free_huge_page to folios | From | John Hubbard <> |
| |
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
| |