Message ID | 20231116012908.392077-1-peterx@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | mm/gup: Unify hugetlb, part 2 | expand |
On Wed, Nov 15, 2023 at 08:28:56PM -0500, Peter Xu wrote: > This patchset is in RFC stage. It's mostly because it is only yet tested on > x86_64 in a VM. Not even compile tested on PPC or any other archs, it > means at least the hugepd patch (patch 11) is mostly untested, or even not > compile tested. Before doing that, I'd like to collect any information > from high level. > > If anyone would like to provide any testing either over hugepd or CONT_PMD > / CONT_PTE on ARM (before I reach there..), or RISCV over 64K Svnapot, > that'll be very much appreciated. I'm copying PPC, ARM, RISCV list for > that. It can be as simple as "./run_vmtests.sh -t gup_test -a" for now, > making sure hugetlb pages can be allocated along the way; the non-hugetlb > gup tests will guaranteed to be covered more or less, I suppose. > > In summary, this is a continuous work for previous series: > > https://lore.kernel.org/all/20230628215310.73782-1-peterx@redhat.com > > And this more or less is my current take to move one more small step > towards merging hugetlb code into generic mm code, as much as we can. > > That part-1 series dropped follow_hugetlb_page(). The plan of this one is > to further drops hugetlb_follow_page_mask(). The hugetlb GUP will use the > same code path for generic mm after whole set applied. > > It means the generic code will need to at least understand hugepd, and > that's already done like so in fast-gup. Fortunately it seems that's the > only major thing I need to teach GUP to share the common path for now > besides normal huge PxD entries. Non-gup can be more challenging, but > that's a question for later. This is great, I looked through quickly and didn't have any profound remarks Thanks, Jason