From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: There is a Tasks RCU stall warning
Date: Tue, 11 Apr 2017 14:44:43 -0700 [thread overview]
Message-ID: <20170411214443.GH1600@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170411173900.00f4b6c6@gandalf.local.home>
On Tue, Apr 11, 2017 at 05:39:00PM -0400, Steven Rostedt wrote:
> On Tue, 11 Apr 2017 17:34:47 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 11 Apr 2017 17:31:33 -0400
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > The thread gets created when I enable the benchmark tracepoint. It just
> > > so happens that my test enables *all* tracepoints, which would of
> > > course include this one as well.
> > >
> > > I'll have to look at this code to see why it is getting missed.
> >
> > Yep, this thread never goes to sleep, but will call cond_resched()
> > periodically. This keeps rcu_tasks() from finishing.
> >
> > Should I add a direct "schedule()" in there instead of a
> > cond_resched(), or do you think rcu_tasks should have cond_resched() be
> > a quiescent state as well?
>
> Actually, I believe this found a bug in my trace_event benchmark
> thread. On a preempt kernel, cond_resched() is a nop and expects to
> only be preempted. Calling schedule() directly should fix everything. I
> shouldn't depend on cond_resched() here.
Works for me!
Hopefully it will also work for your computer. :-)
And whew! Glad to see that the stall warnings worked!
Thanx, Paul
next prev parent reply other threads:[~2017-04-11 21:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 21:18 There is a Tasks RCU stall warning Paul E. McKenney
2017-04-11 21:21 ` Steven Rostedt
2017-04-11 21:32 ` Paul E. McKenney
2017-04-11 21:31 ` Steven Rostedt
2017-04-11 21:34 ` Steven Rostedt
2017-04-11 21:39 ` Steven Rostedt
2017-04-11 21:44 ` Paul E. McKenney [this message]
2017-04-11 21:49 ` Steven Rostedt
2017-04-11 21:56 ` Paul E. McKenney
2017-04-11 22:15 ` Steven Rostedt
2017-04-11 23:01 ` Paul E. McKenney
2017-04-11 23:04 ` Paul E. McKenney
2017-04-11 23:11 ` Paul E. McKenney
2017-04-12 3:23 ` Paul E. McKenney
2017-04-12 13:18 ` Steven Rostedt
2017-04-12 14:19 ` Paul E. McKenney
2017-04-12 14:42 ` Steven Rostedt
2017-04-12 15:18 ` Paul E. McKenney
2017-04-12 15:53 ` Steven Rostedt
2017-04-12 16:26 ` Paul E. McKenney
2017-04-12 16:49 ` Steven Rostedt
2017-04-12 14:48 ` Paul E. McKenney
2017-04-12 14:59 ` Steven Rostedt
2017-04-12 16:27 ` Paul E. McKenney
2017-04-12 16:57 ` Steven Rostedt
2017-04-12 17:07 ` Paul E. McKenney
2017-04-12 17:13 ` Steven Rostedt
2017-04-12 20:02 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170411214443.GH1600@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.