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

David Hildenbrand
2025-05-05T07:01:36Z

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@gmail.com wrote:
>>> From: Fan Ni <fan.ni@samsung.com>
>>>
>>> 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@samsung.com>
>>
>> Reviewed-by: Oscar Salvador <osalvador@suse.de>
>>
>> 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@redhat.com/
> 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