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

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

[zhangqilong]

 > 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.

> 
> --
> Cheers
> 
> David

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

[David Hildenbrand (Red Hat)]

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?

Note that your proposal will likely interact in bad ways with uprobes, 
after removing uprobes again.

-- 
Cheers

David

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

[zhangqilong]

> 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. 

> 
> --
> Cheers
> 
> David

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

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

[zhangqilong]

> 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.

Year, memory consumption overhead is a serious issue, we will conduct a careful evaluation

> 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.

Okay, I'm also trying to gather some test data locally(include microbenchmarks and actual workloads).
I'll attach the results once I have finished. Thank you for your suggestion.

--
Thanks,

Zhang

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

[Zhang Qilong]

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.

Zhang Qilong (2):
  mm/huge_memory: Implementation of THP COW for executable file mmap
  mm/huge_memory: Add sysfs knob for executable THP COW

 Documentation/admin-guide/mm/transhuge.rst |   8 ++
 include/linux/huge_mm.h                    |   5 +
 mm/huge_memory.c                           | 105 ++++++++++++++++++++-
 mm/memory.c                                |  13 +++
 4 files changed, 130 insertions(+), 1 deletion(-)

-- 
2.43.0

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

[Matthew Wilcox]

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.

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

[David Hildenbrand (Red Hat)]

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?

-- 
Cheers

David