Re: [PATCH v4 5/8] rcu: clear defer_qs_pending at expedited IPI entry

[Joel Fernandes <joelagnelf@nvidia.com>]

Hi Paul,

On 7/15/2026 5:01 PM, Paul E. McKenney wrote:
> On Thu, Jun 25, 2026 at 08:42:58PM -0400, Joel Fernandes wrote:
>> The per-CPU clear in __note_gp_changes() (from an earlier commit)
>> runs only when the local CPU notices a normal-GP advance.  When an
>> expedited GP arrives at a CPU whose defer_qs_pending is already
>> PENDING, rcu_read_unlock_special() may skip irq_work queuing due to the
>> pending gate.
>>
>> Clear defer_qs_pending on the IPI target right in rcu_exp_handler().
>> This makes it possible for any arming attempt that follows
>> the IPI within the current GP to be able to queue irq_work again,
>> allowing completion expedited GPs quickly than waiting for one scheduler
>> tick.
>>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> ---
>>  kernel/rcu/tree_exp.h | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
>> index a43469da3926..5be80d255d6a 100644
>> --- a/kernel/rcu/tree_exp.h
>> +++ b/kernel/rcu/tree_exp.h
>> @@ -763,6 +763,12 @@ static void rcu_exp_handler(void *unused)
>>  			 READ_ONCE(rdp->cpu_no_qs.b.exp)))
>>  		return;
>>  
>> +	/*
>> +	 * Clear defer_qs_pending so arming attempts following this IPI
>> +	 * within the current GP can queue irq_work again.
>> +	 */
>> +	rcu_defer_qs_clear(rdp);
> 
> Suppose that there is also a normal grace period pending.  Will clearing
> this cause extra unnecessary activity with respect to that normal
> grace period?  If so, why is that OK?  If not, what prevents it?

There is no unnecessary activity with respect to the normal GP: whatever
this clear allows to be re-armed funnels into
rcu_preempt_deferred_qs_irqrestore(), which reports the normal QS, the
expedited QS and any deboost together. So the enabled activity is shared
work that lets the normal GP end sooner, not work done at its expense.

But also the exp GP IPI could have arrived during an RCU reader and
subsequently needs to do the deferred work. The flag clearing becomes
important then (even if the normal GP previously resulted in the flag
getting set). Patch 4/8 ("rcu: drop redundant defer_qs_pending clear in
irqrestore handler") makes this clear necessary by design: PENDING now
intentionally persists until the next GP-boundary notice, so without
this patch an exp GP arriving mid-window could be reduced to tick
latency.

There is also prevention of pointless clearing from rcu_exp_handler():
we do this only after the "WARN_ON_ONCE(!(expmask & grpmask) ||
cpu_no_qs.b.exp)" early return, so the clear executes only when this CPU
still owes the expedited GP a quiescent state.

Does that answer your question?

thanks,
--
Joel Fernandes