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

[David Hildenbrand (Red Hat)]

On 12/16/25 08:42, zhangqilong wrote:
> > On 12/16/25 03:24, zhangqilong wrote:
> > >    > On 12/15/25 15:00, Matthew Wilcox wrote:
> > > > > On Mon, Dec 15, 2025 at 08:34:05PM +0800, Zhang Qilong wrote:
> > > > > > This patch series implementate THP COW for private executable file
> > > > > > mmap. It's major designed to increase the iTLB cache hit rate for
> > > > > > hot patching application, and we add a new sysfs knob to disable or
> > > > > > enable it.
> > > > >
> > > > > You're going to have to provide data to get this patch in.  We've
> > > > > deliberately not done this in the past due to memory consumption
> > > > overhead.
> > > > > So you need to prove that's now the wrong decision to make.
> > > > >
> > > > > Microbenchmarks would be a bare minimum, but what are really
> > needed
> > > > > are numbers from actual workloads.
> > > >
> > > > In addition, the sysfs toggle is rather horrible. It's rather clear
> > > > that this is not a system-wide setting to be made, as you likely only
> > > > want that behavior (if at all ...) for a handful of special processes I assume?
> > >
> > > Year, it's not a system-wide setting. We consider enabling this option
> > > only when applying hot patches to special processes. If the sysfs
> > > toggle is unavailable, we will evaluate the overall memory impact on
> > > the system after removing it. Thanks very much for your suggestion.
> >
> > I don't think we want this as any kind of default behavior. But the system
> > toggle is really also not what we want. Could we use some per-VMA or per-
> > file hints to affect the policy?
>
> It's really a good idea. Maybe could setting a xx flag to VMA, but it need hold write
> lock and touch VMA. let me have a think how to implement per-VMA or per-file policy
> or other better hints.
>
> I have a thought that, how about adding a new flag(in ptrace, uprobes...) and passing
> to faultin_page() to mark the exec PMD COW policy?
>
> > Note that your proposal will likely interact in bad ways with uprobes, after
> > removing uprobes again.
>
> Year, good catch here, it's really need be seriously considered.

I'll reply on v2 with the issue I have in mind.

--
Cheers

David