* Peter Zijlstra <peterz@xxxxxxxxxxxxx> [241219 13:47]: > On Thu, Dec 19, 2024 at 01:18:23PM -0500, Liam R. Howlett wrote: > > > > For RCU lookups only the mas tree matters -- and its left present there. > > > > > > If you really want to block RCU readers, I would suggest punching a hole > > > in the mm_mt. All the traditional code won't notice anyway, this is all > > > with mmap_lock held for writing. > > > > We don't want to block all rcu readers, we want to block the rcu readers > > that would see the problem - that is, anyone trying to read a particular > > area. > > > > Right now we can page fault in unpopulated vmas while writing other vmas > > to the tree. We are also moving more users to rcu reading to use the > > vmas they need without waiting on writes to finish. > > > > Maybe I don't understand your suggestion, but I would think punching a > > hole would lose this advantage? > > My suggestion was to remove the range stuck in mas_detach from mm_mt. > That is exactly the affected range, no? Yes. But then looping over the vmas will show a gap where there should not be a gap. If we stop rcu readers entirely we lose the advantage. This is exactly the issue that the locking dance was working around :)
