[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170412200231.GL3956@linux.vnet.ibm.com>
Date: Wed, 12 Apr 2017 13:02:31 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: There is a Tasks RCU stall warning
On Wed, Apr 12, 2017 at 01:13:25PM -0400, Steven Rostedt wrote:
> On Wed, 12 Apr 2017 10:07:16 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
>
>
> > > > 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?
>
> Yep.
Also, is the default 10-minute stall warning OK? For purposes of
comparison, when running rcutorture, Tasks RCU grace periods take 2-3
seconds, but of course your mileage may vary.
For whatever it is worth, I set the default ratio of the Tasks RCU
stall-warning time to its average rcutorture grace period to be about
the same as the ratio for other RCU flavors.
And the kernel boot parameter rcupdate.rcu_task_stall_timeout allows
you to set whatever time you want (in jiffies) at boot time. And also
modify it at runtime via sysfs.
Thanx, Paul
Powered by blists - more mailing lists