On 2/5/26 07:31, Lance Yang wrote: > On 2026/2/5 23:09, Dave Hansen wrote: >> On 2/5/26 07:01, Lance Yang wrote: >>> 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. >> >> Which of the writers truly *need* synchronize_rcu()? >> >> What are they doing with the memory that they can't move forward unless >> it's quiescent *now*? > > Without IPIs or synchronize_rcu(), IIUC, we have no way to know if there > are ongoing concurrent lockless page-table walks — the walkers just disable > IRQs and walk.
Yeah, but one aim of RCU is ensuring that readers see valid data but not necessarily the most up to date data. Are there cases where ongoing concurrent lockless page-table walks need to see the writes and they can't tolerate seeing valid but slightly stale data? Don't forget that we also have pesky concurrent lockless page-table walkers called CPUs. They're extra pesky in that they don't even stop for IPIs. ;)
