Messages in this thread | | | Date | Mon, 9 Jan 2023 14:53:51 -0600 | Subject | Re: [PATCH mm-unstable 8/8] mm/hugetlb: convert demote_free_huge_page to folios | From | Sidhartha Kumar <> |
| |
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,
| |