linux-kernel - Re: [PATCH v4 0/3] targeted TLB sync IPIs for lockless page table

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8f5f7617-7a35-4cb2-97b2-0a73c6d9622c@linux.dev>
Date: Thu, 5 Feb 2026 23:28:14 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: "David Hildenbrand (Arm)" <david@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, dave.hansen@...el.com
Cc: Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
 aneesh.kumar@...nel.org, arnd@...db.de, baohua@...nel.org,
 baolin.wang@...ux.alibaba.com, boris.ostrovsky@...cle.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, dev.jain@....com, hpa@...or.com,
 hughd@...gle.com, ioworker0@...il.com, jannh@...gle.com, jgross@...e.com,
 kvm@...r.kernel.org, linux-arch@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 lorenzo.stoakes@...cle.com, mingo@...hat.com, npache@...hat.com,
 npiggin@...il.com, pbonzini@...hat.com, riel@...riel.com,
 ryan.roberts@....com, seanjc@...gle.com, shy828301@...il.com,
 tglx@...utronix.de, virtualization@...ts.linux.dev, will@...nel.org,
 x86@...nel.org, ypodemsk@...hat.com, ziy@...dia.com
Subject: Re: [PATCH v4 0/3] targeted TLB sync IPIs for lockless page table



On 2026/2/5 23:05, David Hildenbrand (Arm) wrote:
> On 2/5/26 16:01, Lance Yang wrote:
>>
>>
>> On 2026/2/5 21:25, David Hildenbrand (Arm) wrote:
>>> On 2/2/26 16:52, Lance Yang wrote:
>>>>
>>>>
>>>>
>>>> Yep, we could replace the IPI with synchronize_rcu() on the sync side:
>>>>
>>>> - Currently: TLB flush → send IPI → wait for walkers to finish
>>>> - With synchronize_rcu(): TLB flush → synchronize_rcu() -> waits for 
>>>> grace period
>>>>
>>>> Lockless walkers (e.g. GUP-fast) use local_irq_disable(); 
>>>> synchronize_rcu() also
>>>> waits for regions with preemption/interrupts disabled, so it should 
>>>> work, IIUC.
>>>>
>>>> And then, the trade-off would be:
>>>> - Read side: zero cost (no per-CPU tracking)
>>>> - Write side: wait for RCU grace period (potentially slower)
>>>>
>>>> For collapse/unshare, that write-side latency might be acceptable :)
>>>>
>>>> @David, what do you think?
>>>
>>> Given that we just fixed the write-side latency from breaking 
>>> Oracle's databases completely, we have to be a bit careful here :)
>>
>> Yep, agreed.
>>
>>>
>>> The thing is: on many x86 configs we don't need *any* TLB flushed or 
>>> RCU syncs.
>>
>> Right. Looks like that is low-hanging fruit. I'll send that out 
>> separately :)
>>
>>>
>>> So "how much slower" are we talking about, especially on bigger/ 
>>> loaded systems?
>>
>> Unfortunately the numbers are pretry bad. On an x86-64 64-core system
>> under high load, each synchronize_rcu() is about *22.9* ms on average ...
>>
>> So for now, neither approach looks good: tracking on the read side adss
>> cost to GUP-fast, and syncing on the write side e.g. synchronize_rcu()
>> is too slow on large systems.
> 
> GUP-fast is 3%, right? Any way we can reduce that to 1% and call it 
> noise? :)

Yes, GUP-fast is ~3%. I'll keep trying to do that, but first getting
the low-hanging fruit done :)