Re: There is a Tasks RCU stall warning

From: Paul E. McKenney
Date: Wed Apr 12 2017 - 13:07:41 EST


On Wed, Apr 12, 2017 at 12:57:22PM -0400, Steven Rostedt wrote:
> On Wed, 12 Apr 2017 09:27:54 -0700
> "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> > On Wed, Apr 12, 2017 at 10:59:37AM -0400, Steven Rostedt wrote:
> > > On Wed, 12 Apr 2017 07:48:00 -0700
> > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > > > > > Like this? (Untested, but builds at least some of the time.)
> > > > > >
> > > > > > Not like that... :-/ Update on its way.
> > > > >
> > > > > Perhaps more like this. Started rcutorture on it, will see how it goes.
> > >
> > > I just love the above discussion with yourself ;-)
> >
> > Talking to oneself used to cause passersby to get really bent out of
> > shape. But one big benefit of ubiquitous cellphones is that now
> > people just assume that you are talking on a cellphone that they
> > cannot see. ;-)
> >
> > > > Do you need this patch? If so, I should do some more work on it to
> > > > eliminate the extra common-case branch on the scheduler fastpath.
> > >
> > > Do I still need this patch? Maybe. :-)
> > >
> > > I changed my benchmark test to call cond_resched_rcu_qs() instead and
> > > that appears to fix the issue. But I'm not sure if there's any other
> > > kthread out there that just calls cond_resched() or schedule().
> > >
> > > Actually, I think it is still a good idea to have it. I believe that it
> > > will still allow synchronize_rcu_tasks() to progress even if there's a
> > > kthread task that is constantly being woken up, and never sleeps when
> > > it calls schedule(), as it may always have the R state.
> >
> > OK, will optimize it a bit. When are you planning to get this in?
> >
>
> Well, I added the use case for synchronize_rcu_tasks() in my current
> for-next. I'll have to make sure I get the schedule_idle() in as well
> as my update to the event benchmark thread as well.
>
> I don't think anything will truly break without it yet. But that's
> assuming there's not another kernel thread somewhere that just spins
> calling schedule.
>
> And this patch will still speed up those that do call
> synchronize_rcu_tasks(). But that's an optimization and not really a
> fix.

The upcoming v4.12 merge window, then?

Thanx, Paul