linux-kernel - Re: [PATCH -v6 2/2] arm64, tlbflush: don't TLBI broadcast if page reused in write fault

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87pl9kf7cn.fsf@DESKTOP-5N7EMDA>
Date: Sat, 15 Nov 2025 08:49:12 +0800
From: "Huang, Ying" <ying.huang@...ux.alibaba.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, Catalin Marinas
 <catalin.marinas@....com>,  Will Deacon <will@...nel.org>,  Andrew Morton
 <akpm@...ux-foundation.org>
Cc: Ryan Roberts <ryan.roberts@....com>,  Barry Song <baohua@...nel.org>,
  Zi Yan <ziy@...dia.com>,  Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
  Vlastimil Babka <vbabka@...e.cz>,  Baolin Wang
 <baolin.wang@...ux.alibaba.com>,  Yang Shi <yang@...amperecomputing.com>,
  "Christoph Lameter (Ampere)" <cl@...two.org>,  Dev Jain
 <dev.jain@....com>,  Anshuman Khandual <anshuman.khandual@....com>,
  Kefeng Wang <wangkefeng.wang@...wei.com>,  Kevin Brodsky
 <kevin.brodsky@....com>,  Yin Fengwei <fengwei_yin@...ux.alibaba.com>,
  linux-arm-kernel@...ts.infradead.org,  linux-kernel@...r.kernel.org,
  linux-mm@...ck.org
Subject: Re: [PATCH -v6 2/2] arm64, tlbflush: don't TLBI broadcast if page
 reused in write fault

"David Hildenbrand (Red Hat)" <david@...nel.org> writes:

> On 14.11.25 09:54, Huang Ying wrote:
>> A multi-thread customer workload with large memory footprint uses
>> fork()/exec() to run some external programs every tens seconds.  When
>> running the workload on an arm64 server machine, it's observed that
>> quite some CPU cycles are spent in the TLB flushing functions.  While
>> running the workload on the x86_64 server machine, it's not.  This
>> causes the performance on arm64 to be much worse than that on x86_64.
>> During the workload running, after fork()/exec() write-protects all
>> pages in the parent process, memory writing in the parent process
>> will cause a write protection fault.  Then the page fault handler
>> will make the PTE/PDE writable if the page can be reused, which is
>> almost always true in the workload.  On arm64, to avoid the write
>> protection fault on other CPUs, the page fault handler flushes the TLB
>> globally with TLBI broadcast after changing the PTE/PDE.  However, this
>> isn't always necessary.  Firstly, it's safe to leave some stale
>> read-only TLB entries as long as they will be flushed finally.
>> Secondly, it's quite possible that the original read-only PTE/PDEs
>> aren't cached in remote TLB at all if the memory footprint is large.
>> In fact, on x86_64, the page fault handler doesn't flush the remote
>> TLB in this situation, which benefits the performance a lot.
>> To improve the performance on arm64, make the write protection fault
>> handler flush the TLB locally instead of globally via TLBI broadcast
>> after making the PTE/PDE writable.  If there are stale read-only TLB
>> entries in the remote CPUs, the page fault handler on these CPUs will
>> regard the page fault as spurious and flush the stale TLB entries.
>> To test the patchset, make the usemem.c from
>> vm-scalability (https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git).
>> support calling fork()/exec() periodically.  To mimic the behavior of
>> the customer workload, run usemem with 4 threads, access 100GB memory,
>> and call fork()/exec() every 40 seconds.  Test results show that with
>> the patchset the score of usemem improves ~40.6%.  The cycles% of TLB
>> flush functions reduces from ~50.5% to ~0.3% in perf profile.
>> Signed-off-by: Huang Ying <ying.huang@...ux.alibaba.com>
>> Reviewed-by: Ryan Roberts <ryan.roberts@....com>
>> Reviewed-by: Barry Song <baohua@...nel.org>
>> Acked-by: Zi Yan <ziy@...dia.com>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Cc: Will Deacon <will@...nel.org>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: David Hildenbrand <david@...hat.com>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
>> Cc: Vlastimil Babka <vbabka@...e.cz>
>> Cc: Baolin Wang <baolin.wang@...ux.alibaba.com>
>> Cc: Yang Shi <yang@...amperecomputing.com>
>> Cc: "Christoph Lameter (Ampere)" <cl@...two.org>
>> Cc: Dev Jain <dev.jain@....com>
>> Cc: Anshuman Khandual <anshuman.khandual@....com>
>> Cc: Kefeng Wang <wangkefeng.wang@...wei.com>
>> Cc: Kevin Brodsky <kevin.brodsky@....com>
>> Cc: Yin Fengwei <fengwei_yin@...ux.alibaba.com>
>> Cc: linux-arm-kernel@...ts.infradead.org
>> Cc: linux-kernel@...r.kernel.org
>> Cc: linux-mm@...ck.org
>> ---
>
> (no need to resend just for acks/rbs, maintainers can pick that up)

Sure.

> Reviewed-by: David Hildenbrand (Red Hat) <david@...nel.org>

Thank you David!

Hi, Maintainers,

I have collected some acks/rbs.  What do you think about the patchset?
What do I need to do for the next step?

---
Best Regards,
Huang, Ying