From: zhangqilong <zhangqilong3@huawei.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>,
Matthew Wilcox <willy@infradead.org>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"lorenzo.stoakes@oracle.com" <lorenzo.stoakes@oracle.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"baolin.wang@linux.alibaba.com" <baolin.wang@linux.alibaba.com>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"npache@redhat.com" <npache@redhat.com>,
"ryan.roberts@arm.com" <ryan.roberts@arm.com>,
"dev.jain@arm.com" <dev.jain@arm.com>,
"baohua@kernel.org" <baohua@kernel.org>,
"lance.yang@linux.dev" <lance.yang@linux.dev>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"rppt@kernel.org" <rppt@kernel.org>,
"surenb@google.com" <surenb@google.com>,
"mhocko@suse.com" <mhocko@suse.com>,
"Wangkefeng (OS Kernel Lab)" <wangkefeng.wang@huawei.com>,
Sunnanyong <sunnanyong@huawei.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH next 0/2] THP COW support for private executable file mmap
Date: Tue, 16 Dec 2025 07:42:44 +0000 [thread overview]
Message-ID: <0ce50058e6254a29baee1271ae0ef31c@huawei.com> (raw)
> 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
next reply other threads:[~2025-12-16 7:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 7:42 zhangqilong [this message]
2025-12-30 21:29 ` David Hildenbrand (Red Hat)
-- strict thread matches above, loose matches on Subject: below --
2025-12-16 2:24 zhangqilong
2025-12-16 2:43 ` David Hildenbrand (Red Hat)
2025-12-16 2:12 zhangqilong
2025-12-15 12:34 Zhang Qilong
2025-12-15 14:00 ` Matthew Wilcox
2025-12-15 14:26 ` David Hildenbrand (Red Hat)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ce50058e6254a29baee1271ae0ef31c@huawei.com \
--to=zhangqilong3@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sunnanyong@huawei.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox