Re: [PATCH 00/45] hugetlb pagewalk unification

[David Hildenbrand <david@redhat.com>]

On 04.07.24 06:30, Oscar Salvador wrote:
> Hi all,
> 
> During Peter's talk at the LSFMM, it was agreed that one of the things
> that need to be done in order to further integrate hugetlb into mm core,
> is to unify generic and hugetlb pagewalkers.
> I started with this one, which is unifying hugetlb into generic
> pagewalk, instead of having its hugetlb_entry entries.
> Which means that pmd_entry/pte_entry(for cont-pte) entries will also deal with
> hugetlb vmas as well, and so will new pud_entry entries since hugetlb can be
> pud mapped (devm pages as well but we seem not to care about those with
> the exception of hmm code).
> 
> The outcome is this RFC.

First of all, a good step into the right direction, but maybe not what 
we want long-term. So I'm questioning whether we want this intermediate 
approach. walk_page_range() and friends are simply not a good design 
(e.g., indirect function calls).


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.

-- 
Cheers,

David / dhildenb