Re: There is a Tasks RCU stall warning

[Paul E. McKenney]

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