Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines

[Paul E. McKenney]

On Thu, Sep 17, 2026 at 02:14:57PM +0200, Frederic Weisbecker wrote:
> Le Wed, Sep 16, 2026 at 08:41:36AM -0700, Paul E. McKenney a écrit :
> > On Wed, Sep 16, 2026 at 05:23:31PM +0200, Frederic Weisbecker wrote:
> > > Le Wed, Sep 16, 2026 at 07:55:02AM -0700, Paul E. McKenney a écrit :
> > > > Perhaps in rcu_core() in kernels booted with use_softirq?  I am thinking
> > > > specifically of the checks for deferred quiescent states.  I don't (yet)
> > > > see a need to modify rcu_check_quiescent_state().
> > > > 
> > > > Maybe other places as well.  ;-)
> > > 
> > > Hmm this tracking would have to happen on preempt_schedule() just like we
> > > do for PREEMPT_RCU. Or am I missing something? And then we would need a
> > > list scan of those tasks.
> > 
> > I am thinking of the case where a trampoline is interrupted before entering
> > (or after leaving) its RCU Tasks Trace read-side critical section.  Then
> > there is a softirq handler on the back of that interrupt handler, and
> > RCU_SOFTIRQ is invoked, calling rcu_core().  Specifically:
> > 
> > 	/* Report any deferred quiescent states if preemption enabled. */
> > 	if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && (!(preempt_count() & PREEMPT_MASK))) {
> > 		rcu_preempt_deferred_qs(current);
> > 	} else if (rcu_preempt_need_deferred_qs(current)) {
> > 		guard(irqsave)();
> > 		set_need_resched_current();
> > 	}
> > 
> > Preemption is enabled, but we should not report a quiescent state because
> > we have interrupted a trampoline.  Correct?
> 
> Right!
>  
> > > Or we can build the blocked task list handling, that we already have for PREEMPT_RCU,
> > > when CONFIG_RCU_TASKS && !CONFIG_PREEMPT_RCU. We would just only add tasks when
> > > preempted in .text.rcu_no_qs since rcu_read_lock() would still disable
> > > preemption on normal explicit readers. So I wouldn't expect more overhead due to
> > > that blocked list tracking built since it would rarely track tasks.
> > 
> > Yes, we could avoid the list of tasks by treating the preemption within
> > the trampoline the same as preemption within an RCU read-side critical
> > section, but there might not be an rcu_read_unlock() to clean up.
> > Which could be a problem.
> 
> Ah yes, good point.
> 
> > 
> > Trampolines that transfer control to tracing code could supply the needed
> > cleanup call.  But last I checked, there were trampolines that transferred
> > directly back to the original code, with no opportunity for cleaning up.
> > 
> > Or am I still missing a trick here?
> 
> You're right. So we'll indeed need to reuse the deferred qs points here.

Except this is getting a bit involved.

Don't get me wrong, if Josef is happy to take this on, far be it from me
to stand in his way.  But if not, we should be willing to treat this
optimization as a follow-on effort, whether by Josef or someone else.

							Thanx, Paul