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? :)
--
Cheers,
David
