On 09.08.24 18:08, Peter Xu wrote:
Overview ======== This series is based on mm-unstable, commit 98808d08fc0f of Aug 7th latest, plus dax 1g fix [1]. Note that this series should also apply if without the dax 1g fix series, but when without it, mprotect() will trigger similar errors otherwise on PUD mappings. This series implements huge pfnmaps support for mm in general. Huge pfnmap allows e.g. VM_PFNMAP vmas to map in either PMD or PUD levels, similar to what we do with dax / thp / hugetlb so far to benefit from TLB hits. Now we extend that idea to PFN mappings, e.g. PCI MMIO bars where it can grow as large as 8GB or even bigger. Currently, only x86_64 (1G+2M) and arm64 (2M) are supported. The last patch (from Alex Williamson) will be the first user of huge pfnmap, so as to enable vfio-pci driver to fault in huge pfn mappings. Implementation ============== In reality, it's relatively simple to add such support comparing to many other types of mappings, because of PFNMAP's specialties when there's no vmemmap backing it, so that most of the kernel routines on huge mappings should simply already fail for them, like GUPs or old-school follow_page() (which is recently rewritten to be folio_walk* APIs by David).
Indeed, skimming most patches, there is very limit core-mm impact. I expected much more :)
I suspect primarily because DAX already paved the way. And as DAX likely supports fault-after-fork, which is why the fork() case wasn't relevant before.
-- Cheers, David / dhildenb
