Messages in this thread | | | Date | Wed, 12 Apr 2017 10:07:16 -0700 | From | "Paul E. McKenney" <> | Subject | Re: There is a Tasks RCU stall warning |
| |
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@linux.vnet.ibm.com> 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@linux.vnet.ibm.com> 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
| |