Re: [PATCH v5 0/4] mm/huge_memory: copy PMDs at fork like the PTE path does

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 04 Nov 2026 21:40:54 +0100 Konstantin Khorenko <khorenko@virtuozzo.com> 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.