On Thu, Dec 19, 2024 at 10:55 AM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > * 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 :) Sorry for not participating in the discussion, folks. I'm down with a terrible flu and my brain is not working well. I'll catch up once I get better. >
