On Wed, 04 Nov 2026 21:40:54 +0100 Konstantin Khorenko <[email protected]>
wrote:
> copy_huge_pmd() decides what to copy at fork by its own rules, apart
> from copy_present_ptes(): a lockless check for special PMDs, and a skip
> of every file THP. Following David's review of v3, this series makes it
> decide the way the PTE path does, under the page table lock, with
> vm_normal_page_pmd(). That fixes the two bugs v1-v3 were about. The
> patches:
>
> 1. folio_dup_file_rmap_pmd() duplicated a PMD mapping as HPAGE_PMD_NR
> PTE mappings. It had no caller until patch 2.
> 2. File THPs are copied at fork instead of being refaulted by the
> child, as their PTEs would be.
> 3. The special-PMD read moves under the lock. That closes the race with
> a driver zap (vfio-pci, panthor) and the missing page table deposit
> on ppc64 hash that Sashiko found in v1.
> 4. A selftest for 1 and 2.
>
> ...
>
> Cost
> ====
>
> fork() now copies file THPs instead of leaving them to a refault, which
> costs fork() a reference, an rmap update and a counter per huge PMD and
> saves the child a fault per huge PMD it touches. fork() of a process
> with 4 GB of shmem THPs mapped MAP_PRIVATE and an anon_vma on the VMA,
> medians of 2000 forks:
>
> +-----------------------+------------+-------------------------+
> | kernel | fork() | fork(), child reads all |
> +-----------------------+------------+-------------------------+
> | 7.3-rc7 | 86-129 us | 2380-2620 us |
> | 7.3-rc7 + this series | 230-355 us | 820-930 us |
> +-----------------------+------------+-------------------------+
The second column assumes that the child touches all the file THPs,
yes? If the child touches only a small proportion of those mappings,
or just does fork+exec, that changes the "Cost" comparison?
And on ppc64 hash-mode setups this also allocates deposited page tables
for mappings which the child might never touch? So a modest increase
in memory use is to be expected? I can't say I care about this
(sorry!).
But I worry that this change is not an overall win for thp-file
mappings, which are the common case.
I'm not understanding why we need to mess with thp-file behavior at all
in order to address a special-PMD bug?
> Notes
> =====
>
> - drm_gem_shmem and mshv_vtl map special PMDs with
> vmf_insert_pfn_pmd() as well.
> - copy_huge_pud() still differs from the PMD tail in that it does not
> mark a shared PUD clean in the child or handle uffd bits.
>
> ...
>
> Reproducer.
Changelog is soooo long. I replaced this Reproducer section with simply
- A reproducer is at the Link;
So interested people can still find it.
Anyway, bugfixes come first so I'll fix the selftest pmd_psize thing
and I'll toss this onto the pile, thanks.
I'm attempting to runtime test this on local LLM-driven live kernel
test setup, but it keeps on kicking me out and calling me a
cybercriminal. Sigh. Giving up.
