On Wed, May 22, 2024 at 11:13:53AM +1000, Nicholas Piggin wrote: > From the mm/ side of things, hugetlb page tables are always walked via > the huge vma which knows the page size and could align address... I > guess except for fast gup? Which should be read-only. So okay you do > need to replicate huge ptes for fast gup at least. Any others? We are trying to get away from this. We want all content in the page table to be walkable via the normal pud/pmd/pte/etc functions and the special huge VMA limited to only weird hugetlbfs internals. It should not leak into the arch. > There's going to need to be a little more to it. __hash_page_huge sets > PTE accessed and dirty for example, so if we allow any PTE readers to > check the non-0th pte we would have to do something about that. Ryan added a special function to get the access and dirty flags from a CONTIG PTE, the arch can do the right thing here. The case where there was a CONTIG PTE that spanned two PMD entries might be some trouble though. > How do you deal with dirty/accessed bits for other subarchs? ARM and RISCV verions will combine the access flags from every sub pte. Their HW is allowed to set dirty/access bits on any PTE in a contiguos set. Jason
