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

[Lance Yang]

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 :)