Re: [PATCH] mm/hugetlb: Convert &folio->page to folio_page(folio, 0)

[David Hildenbrand <david@redhat.com>]

On 23.04.25 20:50, Matthew Wilcox wrote:
> On Fri, Apr 18, 2025 at 03:42:45PM -0700, Fan Ni wrote:
>>>>   	result = install_pmd
>>>> -			? set_huge_pmd(vma, haddr, pmd, &folio->page)
>>>> +			? set_huge_pmd(vma, haddr, pmd, folio_page(folio, 0))
>>>>   			: SCAN_SUCCEED;
>>>
>>> I feel that set_huge_pmd() should take a folio.
>> There is a patch on the mailing list for it,
>> https://lore.kernel.org/linux-mm/20240817095122.2460977-5-wangkefeng.wang@huawei.com/
>>
>> If the above patch is needed, do_set_pmd() should be converted to use folio.
> 
> Maybe?  I think we'll eventually want to support folios larger than PMD
> size.  So I don't want to pass in a folio here unless we can calculate the
> precise PMD-size chunk we want to map from this folio given the
> information available in vmf.  I know that today the implementation
> does this:
> 
>          if (folio_order(folio) != HPAGE_PMD_ORDER)
>                  return ret;
>          page = &folio->page;
> 
> but eventually we should do better than that.  And I don't want to
> lose the information about which page in the folio we really want
> to map.  So have a think about what the right interface should be
> (passing in a page?  folio + offset-in-number-of-pages?  Something
> involving the PFN?)
> 
> The obvious hurdle is folio_add_file_rmap_pmd() which today takes both a
> folio and a page.

The interface is prepared for that use case: I decided to pass in folio 
+ page to allow for folios that span multiple PMDs. (obviously, the 
internal implementation does not allow for that)

We could later change it to folio + offset, but should do so for all 
rmap functions consistently.

-- 
Cheers,

David / dhildenb