From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
jiangshanlai@gmail.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com,
oleg@redhat.com, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH tip/core/rcu 06/10] trace: Eliminate cond_resched_rcu_qs() in favor of cond_resched()
Date: Sun, 25 Feb 2018 09:49:27 -0800 [thread overview]
Message-ID: <20180225174927.GC2855@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180224151240.0d63a059@vmware.local.home>
On Sat, Feb 24, 2018 at 03:12:40PM -0500, Steven Rostedt wrote:
> On Fri, 1 Dec 2017 11:21:40 -0800
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > Now that cond_resched() also provides RCU quiescent states when
> > needed, it can be used in place of cond_resched_rcu_qs(). This
> > commit therefore makes this change.
>
> Are you sure this is true?
Up to a point. If a given CPU has been blocking an RCU grace period for
long enough, that CPU's rcu_dynticks.rcu_need_heavy_qs will be set, and
then the next cond_resched() will be treated as a cond_resched_rcu_qs().
However, to your point, if there is no grace period in progress or if
the current grace period is not waiting on the CPU in question or if
the grace-period kthread is starved of CPU, then cond_resched() has no
effect on RCU. Unless of course it results in a context switch.
> I just bisected a lock up on my machine down to this commit.
>
> With CONFIG_TRACEPOINT_BENCHMARK=y
>
> # cd linux.git/tools/testing/selftests/ftrace/
> # ./ftracetest test.d/ftrace/func_traceonoff_triggers.tc
>
> Locks up with a backtrace of:
>
> [ 614.186509] INFO: rcu_tasks detected stalls on tasks:
Ah, but this is RCU-tasks! Which never sets rcu_dynticks.rcu_need_heavy_qs,
thus needing a real context switch.
Hey, when you said that synchronize_rcu_tasks() could take a very long
time, I took you at your word! ;-)
Does the following (untested, probably does not even build) patch make
cond_resched() take a more peremptory approach to RCU-tasks?
Thanx, Paul
------------------------------------------------------------------------
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0c337f5ba3c4..5155fe5e7702 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1088,12 +1088,16 @@ EXPORT_SYMBOL_GPL(rcu_is_watching);
void rcu_request_urgent_qs_task(struct task_struct *t)
{
int cpu;
+ struct rcu_dynticks *rdtp;
barrier();
cpu = task_cpu(t);
if (!task_curr(t))
return; /* This task is not running on that CPU. */
- smp_store_release(per_cpu_ptr(&rcu_dynticks.rcu_urgent_qs, cpu), true);
+ rdtp = per_cpu_ptr(&rcu_dynticks, cpu);
+ WRITE_ONCE(rdtp->rcu_need_heavy_qs, true);
+ /* Store rcu_need_heavy_qs before rcu_urgent_qs. */
+ smp_store_release(&rdtp->rcu_urgent_qs, true);
}
#if defined(CONFIG_PROVE_RCU) && defined(CONFIG_HOTPLUG_CPU)
next prev parent reply other threads:[~2018-02-25 17:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 19:21 [PATCH tip/core/rcu 0/10] Don not IPI offline CPUs, de-emphasize cond_resched_rcu_qs() Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 01/10] sched: Stop resched_cpu() from sending IPIs to offline CPUs Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 02/10] sched: Stop switched_to_rt() " Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 03/10] netfilter: Eliminate cond_resched_rcu_qs() in favor of cond_resched() Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 04/10] mm: " Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 05/10] workqueue: " Paul E. McKenney
2017-12-02 1:06 ` Lai Jiangshan
2017-12-04 18:28 ` Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 06/10] trace: " Paul E. McKenney
2018-02-24 20:12 ` Steven Rostedt
2018-02-25 17:49 ` Paul E. McKenney [this message]
2018-02-25 18:17 ` Paul E. McKenney
2018-02-25 18:39 ` Paul E. McKenney
2018-02-27 2:29 ` Steven Rostedt
2018-02-27 15:36 ` Paul E. McKenney
2018-02-28 23:12 ` Steven Rostedt
2018-03-01 1:21 ` Paul E. McKenney
2018-03-01 5:04 ` Steven Rostedt
2018-03-01 20:48 ` Paul E. McKenney
2018-03-02 20:06 ` Steven Rostedt
2018-03-03 0:54 ` Paul E. McKenney
2018-02-26 4:57 ` Steven Rostedt
2018-02-26 5:47 ` Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 07/10] softirq: " Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 08/10] fs: " Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 09/10] doc: " Paul E. McKenney
2017-12-01 19:21 ` [PATCH tip/core/rcu 10/10] rcu: Account for rcu_all_qs() in cond_resched() Paul E. McKenney
2017-12-02 8:56 ` Peter Zijlstra
2017-12-02 12:22 ` Paul E. McKenney
2017-12-02 13:55 ` Peter Zijlstra
2018-02-24 20:18 ` Steven Rostedt
2018-02-25 17:52 ` 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=20180225174927.GC2855@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.