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
