On Thu, Jun 20, 2019 at 04:59:30PM -0500, Scott Wood wrote:
> On Thu, 2019-06-20 at 14:10 -0700, Paul E. McKenney wrote:
> > On Tue, Jun 18, 2019 at 08:19:07PM -0500, Scott Wood wrote:
> > > [Note: Just before posting this I noticed that the invoke_rcu_core stuff
> > > is part of the latest RCU pull request, and it has a patch that
> > > addresses this in a more complicated way that appears to deal with the
> > > bare irq-disabled sequence as well.
> >
> > Far easier to deal with it than to debug the lack of it. ;-)
> >
> > > Assuming we need/want to support such sequences, is the
> > > invoke_rcu_core() call actually going to result in scheduling any
> > > sooner? resched_curr() just does the same setting of need_resched
> > > when it's the same cpu.
> > > ]
> >
> > Yes, invoke_rcu_core() can in some cases invoke the scheduler sooner.
> > Setting the CPU-local bits might not have effect until the next interrupt.
>
> Maybe I'm missing something, but I don't see how (in the non-use_softirq
> case). It just calls wake_up_process(), which in resched_curr() will set
> need_resched but not do an IPI-to-self.
The common non-rt case will be use_softirq. Or are you referring
specifically to this block of code in current -rcu?
} else if (exp && irqs_were_disabled && !use_softirq &&
!t->rcu_read_unlock_special.b.deferred_qs) {
// Safe to awaken and we get no help from enabling
// irqs, unlike bh/preempt.
invoke_rcu_core();
Thanx, Paul
