Re: [PATCH] mm/mmu_notifier: Remove non_block_start/end() from notifier invocation

[Paul E. McKenney]

On Tue, Aug 25, 2026 at 06:05:54PM +0100, David Woodhouse wrote:
> On Tue, 2026-08-25 at 09:47 -0700, Paul E. McKenney wrote:
> > 
> > On the tail latencies...
> > 
> > The easiest way to reduce them is to require that preemption be disabled
> > across srcu_read_lock_atomic()/srcu_read_unlock_atomic() regions and
> > across all calls to synchronize_srcu_atomic().  Without that, the problem
> > is that the scheduler does not know that the spinning is pointless,
> > and we cannot use the blocking primitives that we could otherwise use
> > to tell it what is going on.
> > 
> > So, is it feasible to simply require preemption be disabled as called
> > out above?
> 
> I'd experimented with disabling it around the GP driver loop in
> synchronize_srcu_atomic() as seen in
> https://git.infradead.org/?p=users/dwmw2/linux.git;a=commitdiff;h=07165e79340e
> and that didn't seem to change anything (which seems reasonable, as
> it's the *waiters* that were descheduled, not the threads driving the
> actual GP). So your suggestion that we do it around the whole function
> certainly makes sense too. I'll test it.
> 
> I do wonder if we're really doing the right thing here by selfishly
> blocking preemption because we want a specific tail latency to remain
> low in a contended system. Maybe we should allow preemption and trust
> that the right thing will happen? Maybe the p100 isn't the right
> benchmark to be chasing... I'm looking at it because Sean expressed
> concerns about it, but it's not the only consideration.

My concern is algorithmic, not benchmark optimization.

Suppose that there is only one CPU, or, alternatively, that one of the
atomic SRCU readers is pinned to the same CPU occupied by the (higher
priority) task running synchronize_srcu_atomic().  In this case, the
call to synchronize_srcu_atomic() uselessly burns CPU time until its
priority decays, real-time throttling kicks in, or in some configurations,
maybe never.

Requiring preemption be disabled across both the atomic SRCU readers
and the synchronize_srcu_atomic() avoids this, at least when running on
bare metal.  My (perhaps naive) hope is that guest OSes get some use
out of those cpu_relax() calls.

> I'll have another look, but right now I'm in the middle of rebasing
> onto kvm/next and the whole nested story has fallen apart and I don't
> know (yet) what broke... :)

No hurry.  I am allowing preemption (but dangerously as noted above)
for the moment, and can easily add lockdep checks if and when.

Plus I need to turn my rcutorture changes from shameless hacks into
something maintainable.  And find and fix the inevitable remaining bugs.

							Thanx, Paul