Re: [PATCH v3 3/4] mm/hugetlb: Refactor __unmap_hugepage_range() to take folio instead of page

[David Hildenbrand]

On 04.05.25 23:35, Fan Ni wrote:
> On Wed, Apr 30, 2025 at 09:58:35AM +0200, Oscar Salvador wrote:
> > On Mon, Apr 28, 2025 at 10:11:46AM -0700, nifan.cxl@xxxxxxxxx wrote:
> > > From: Fan Ni <fan.ni@xxxxxxxxxxx>
> > >
> > > The function __unmap_hugepage_range() has two kinds of users:
> > > 1) unmap_hugepage_range(), which passes in the head page of a folio.
> > >     Since unmap_hugepage_range() already takes folio and there are no other
> > >     uses of the folio struct in the function, it is natural for
> > >     __unmap_hugepage_range() to take folio also.
> > > 2) All other uses, which pass in NULL pointer.
> > >
> > > In both cases, we can pass in folio. Refactor __unmap_hugepage_range() to
> > > take folio.
> > >
> > > Signed-off-by: Fan Ni <fan.ni@xxxxxxxxxxx>
> >
> > Reviewed-by: Oscar Salvador <osalvador@xxxxxxx>
> >
> > But:
> >
> > >   void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
> > >   			    unsigned long start, unsigned long end,
> > > -			    struct page *ref_page, zap_flags_t zap_flags)
> > > +			    struct folio *folio, zap_flags_t zap_flags)
> >
> > I think we are kinda losing information here. ref_ was a good hint
> > and...
>
> Hi Oscar,
>
> Thanks for the feedback.
> Since the sugguested change here is minor and does not affect the
> function, and we do not have a aligned opinion here.
> https://lore.kernel.org/linux-mm/b23ef51b-1284-4168-8157-432c3e045788@xxxxxxxxxx/
> I will leave it as it is until there are more pushes for the change.

I don't think we're losing any information. :) Especially if nowhere 
else in the kernel we use the term "ref_page" or "ref_folio". And things 
like put_ref_page(), free_unref_folios() ... talk about dropping 
references not "this is the reference folio".

"folio_to_unmap" might be clearer, but then, I think we should just use 
a single folio variable in that function.

This function might benefit from kerneldoc, though :)

--
Cheers,

David / dhildenb