Le 21/03/2024 à 23:07, peterx@xxxxxxxxxx a écrit : > From: Peter Xu <peterx@xxxxxxxxxx> > > v3: > - Rebased to latest mm-unstalbe (a824831a082f, of March 21th) > - Dropped patch to introduce pmd_thp_or_huge(), replace such uses (and also > pXd_huge() users) with pXd_leaf() [Jason] > - Add a comment for CONFIG_PGTABLE_HAS_HUGE_LEAVES [Jason] > - Use IS_ENABLED() in follow_huge_pud() [Jason] > - Remove redundant none pud check in follow_pud_mask() [Jason] > > rfc: https://lore.kernel.org/r/20231116012908.392077-1-peterx@xxxxxxxxxx > v1: https://lore.kernel.org/r/20231219075538.414708-1-peterx@xxxxxxxxxx > v2: https://lore.kernel.org/r/20240103091423.400294-1-peterx@xxxxxxxxxx > > The series removes the hugetlb slow gup path after a previous refactor work > [1], so that slow gup now uses the exact same path to process all kinds of > memory including hugetlb. > > For the long term, we may want to remove most, if not all, call sites of > huge_pte_offset(). It'll be ideal if that API can be completely dropped > from arch hugetlb API. This series is one small step towards merging > hugetlb specific codes into generic mm paths. From that POV, this series > removes one reference to huge_pte_offset() out of many others. > > One goal of such a route is that we can reconsider merging hugetlb features > like High Granularity Mapping (HGM). It was not accepted in the past > because it may add lots of hugetlb specific codes and make the mm code even > harder to maintain. With a merged codeset, features like HGM can hopefully > share some code with THP, legacy (PMD+) or modern (continuous PTEs). > > To make it work, the generic slow gup code will need to at least understand > hugepd, which is already done like so in fast-gup. Due to the specialty of > hugepd to be software-only solution (no hardware recognizes the hugepd > format, so it's purely artificial structures), there's chance we can merge > some or all hugepd formats with cont_pte in the future. That question is > yet unsettled from Power side to have an acknowledgement. As of now for > this series, I kept the hugepd handling because we may still need to do so > before getting a clearer picture of the future of hugepd. The other reason > is simply that we did it already for fast-gup and most codes are still > around to be reused. It'll make more sense to keep slow/fast gup behave > the same before a decision is made to remove hugepd. > It is not true that hugepd is a software-only solution. Powerpc 8xx HW matches the hugepd topology for 8M pages. Christophe
