On 01/07/23 01:31, Matthew Wilcox wrote:
> On Fri, Jan 06, 2023 at 05:11:36PM -0800, Mike Kravetz wrote:
> > On 01/03/23 13:13, Sidhartha Kumar wrote:
> > > @@ -3477,15 +3477,15 @@ static int demote_free_huge_page(struct hstate *h, struct page *page)
> > > mutex_lock(&target_hstate->resize_lock);
> > > for (i = 0; i < pages_per_huge_page(h);
> > > i += pages_per_huge_page(target_hstate)) {
> > > - subpage = nth_page(page, i);
> > > - folio = page_folio(subpage);
> > > + subpage = folio_page(folio, i);
> > > + subfolio = page_folio(subpage);
> >
> > 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.
--
Mike Kravetz
