Re: [PATCH next v2 0/2] THP COW support for private executable file mmap

[David Hildenbrand (Red Hat)]

On 12/26/25 11:03, Zhang Qilong wrote:
> This patch series implementate THP COW for private executable file mmap.
> It's major designed to improve the performance of hotpatch programs, and
> reusing 'vma->vm_flags' hints to determine whether to trigger the exec
> THP COW.
>
> The MySQL (Ver 8.0.25) test results on AMD are as follows:
>
> -------------------------------------------------------------------
>                   | Exec mmap Rss(kB)  | Measured tpmC (NewOrders) |
> -----------------|--------------------|---------------------------|
>   base(page COW)  |       32868        |        339686             |
> -----------------|--------------------|---------------------------|
>   exec THP COW    |       43516        |        371324             |
> -------------------------------------------------------------------
>
> The MySQL using exec THP COW consumes an additional 10648 kB of memory
> but achieves 9.3% performance improvement in the scenario of hotpatch.
> Additionally, another our internal program achieves approximately a 5%
> performance improvement as well.
>
> As result, using exec THP COW will consume additional memory. The
> additional memory consumption may be negligible for the current system.
> It's necessary to balance the memory consumption with the performance
> impact.

I agree with Willy that "negligible" is the wrong word. Assume you're 
using uprobes and end up firing up the same executable in many 
processes. Each process will suddenly consume 2M vs. 4k just for 
installing a single uprobe. Of course, VM_HUGEPAGE mitigates this.

But really, this is the first time that we are using large anon folios 
in MAP_PRIVATE file mappings IIRC.

Take a look at kernel/events/uprobes.c:__uprobe_write(), which I 
prepared to deal with large folios.

But the removal logic for zapping pages when removing uprobes will not 
be able to reclaim the memory in case we over-allocated memory during 
the COW fault. We'll be zapping a single PTE only and *not* restoring 
the original file THP PMD.

Zapping more is rather complicated (doable, but complicated), and I'm 
not particularly keen about adding that complexity there.

Long story short: this is the first time we allocate anon THPs in such 
areas and I wouldn't be surprised if there are more problems lurking 
somewhere.

--
Cheers

David