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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <e133c19e47324cce97a1c8f3752489c1@huawei.com>
Date: Tue, 16 Dec 2025 02:24:40 +0000
From: zhangqilong <zhangqilong3@...wei.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, Matthew Wilcox
	<willy@...radead.org>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>, "corbet@....net"
	<corbet@....net>, "ziy@...dia.com" <ziy@...dia.com>,
	"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "npache@...hat.com"
	<npache@...hat.com>, "ryan.roberts@....com" <ryan.roberts@....com>,
	"dev.jain@....com" <dev.jain@....com>, "baohua@...nel.org"
	<baohua@...nel.org>, "lance.yang@...ux.dev" <lance.yang@...ux.dev>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>,
	"surenb@...gle.com" <surenb@...gle.com>, "mhocko@...e.com" <mhocko@...e.com>,
	"Wangkefeng (OS Kernel Lab)" <wangkefeng.wang@...wei.com>, Sunnanyong
	<sunnanyong@...wei.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH next 0/2] THP COW support for private executable file mmap

 > 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