Re: [PATCH 00/45] hugetlb pagewalk unification

[Peter Xu <peterx@redhat.com>]

Hey, David,

On Thu, Jul 04, 2024 at 12:44:38PM +0200, David Hildenbrand wrote:
> There are roughly two categories of page table walkers we have:
> 
> 1) We actually only want to walk present folios (to be precise, page
>    ranges of folios). We should look into moving away from the walk the
>    page walker API where possible, and have something better that
>    directly gives us the folio (page ranges). Any PTE batching would be
>    done internally.
> 
> 2) We want to deal with non-present folios as well (swp entries and all
>    kinds of other stuff). We should maybe implement our custom page
>    table walker and move away from walk_page_range(). We are not walking
>    "pages" after all but everything else included :)
> 
> Then, there is a subset of 1) where we only want to walk to a single address
> (a single folio). I'm working on that right now to get rid of follow_page()
> and some (IIRC 3: KSM an daemon) walk_page_range() users. Hugetlb will still
> remain a bit special, but I'm afraid we cannot hide that completely.

Maybe you are talking about the generic concept of "page table walker", not
walk_page_range() explicitly?

I'd agree if it's about the generic concept. For example, follow_page()
definitely is tailored for getting the page/folio.  But just to mention
Oscar's series is only working on the page_walk API itself.  What I see so
far is most of the walk_page API users aren't described above - most of
them do not fall into category 1) at all, if any. And they either need to
fetch something from the pgtable where having the folio isn't enough, or
modify the pgtable for different reasons.

A generic pgtable walker looks still wanted at some point, but it can be
too involved to be introduced together with this "remove hugetlb_entry"
effort.

To me, that future work is not yet about "get the folio, ignore the
pgtable", but about how to abstract different layers of pgtables, so the
caller may get a generic concept of "one pgtable entry" with the level/size
information attached, and process it at a single place / hook, and perhaps
hopefully even work with a device pgtable, as long as it's a radix tree.

[Adding Jason into the loop too. PS: Oscar, please consider copying Jason
 for the works too; Jason provided great lots of useful discussions in the
 past on relevant topics]

Thanks,

-- 
Peter Xu