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

[David Woodhouse]

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.

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature