From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Byungchul Park <byungchul.park@lge.com>
Cc: josh@joshtriplett.org, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu: Avoid unnecessary contention of rcu node lock
Date: Wed, 16 Nov 2016 11:29:35 -0800 [thread overview]
Message-ID: <20161116192935.GL3612@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161116044931.GD2279@X58A-UD3R>
On Wed, Nov 16, 2016 at 01:49:31PM +0900, Byungchul Park wrote:
> On Wed, Nov 09, 2016 at 05:57:13PM +0900, Byungchul Park wrote:
> > It's unnecessary to try to print stacks of blocked tasks in the case
> > that ndetected == 0. Furthermore, calling rcu_print_detail_task_stall()
> > causes to acquire rnp locks as many times as the number of leaf nodes
> > plus one for root node. It's unnecessary at all in the case.
Please accept my apologies for the delay -- the last couple of weeks
were quite busy, and I needed to give this the attention that it
deserves.
> Hello,
>
> I have two questions. Could you answer them?
>
> 1. What do you think about this patch?
This patch would be a performance optimization if ndetected were often
zero at the end of the loop in print_other_cpu_stall(). However, for
this to happen, the stall would have to be almost exactly 21 seconds
in duration, which seems unlikely and which also proves to be unlikely
in actual practice.
If there was any performance or readability downside whatsoever for
this patch, I would of course need to reject it. However, it appears
to be free of any performance degradation and could be said to slightly
increase readability.
I took the patch and reworked the commit log as shown below.
That said, it is quite rare for me to accept a patch with such a low
probability of reducing overhead.
> 2. Is there a tree where patches about rcu are pulled into, before
> being pulled into mainline tree?
> For example, tip tree in case of scheduler patches.
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This is pulled into -tip, as Steven said.
Thanx, Paul
> It would be appriciated if you answer them.
>
> Thank you in advance,
> Byungchul
------------------------------------------------------------------------
commit 9183b76a762e0e73fd362cf2563f6492ae7fc193
Author: Byungchul Park <byungchul.park@lge.com>
Date: Wed Nov 9 17:57:13 2016 +0900
rcu: Only dump stalled-tasks stacks if there was a real stall
The print_other_cpu_stall() function currently unconditionally invokes
rcu_print_detail_task_stall(). This is OK because if there was a stall
sufficient to cause print_other_cpu_stall() to be invoked, that stall
is very likely to persist through the entire print_other_cpu_stall()
execution. However, if the stall did not persist, the variable ndetected
will be zero, and that variable is already tested in an "if" statement.
Therefore, this commit moves the call to rcu_print_detail_task_stall()
under that pre-existing "if" to improve readability, with a very rare
reduction in overhead.
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
[ paulmck: Reworked commit log. ]
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 2c399db6df6e..b11d00ad1213 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1504,6 +1504,9 @@ static void print_other_cpu_stall(struct rcu_state *rsp, unsigned long gpnum)
(long)rsp->gpnum, (long)rsp->completed, totqlen);
if (ndetected) {
rcu_dump_cpu_stacks(rsp);
+
+ /* Complain about tasks blocking the grace period. */
+ rcu_print_detail_task_stall(rsp);
} else {
if (READ_ONCE(rsp->gpnum) != gpnum ||
READ_ONCE(rsp->completed) == gpnum) {
@@ -1520,9 +1523,6 @@ static void print_other_cpu_stall(struct rcu_state *rsp, unsigned long gpnum)
}
}
- /* Complain about tasks blocking the grace period. */
- rcu_print_detail_task_stall(rsp);
-
rcu_check_gp_kthread_starvation(rsp);
panic_on_rcu_stall();
next prev parent reply other threads:[~2016-11-16 19:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 8:57 [PATCH] rcu: Avoid unnecessary contention of rcu node lock Byungchul Park
2016-11-16 4:49 ` Byungchul Park
2016-11-16 13:59 ` Steven Rostedt
2016-11-16 19:29 ` Paul E. McKenney [this message]
2016-11-17 3:38 ` Byungchul Park
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=20161116192935.GL3612@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=byungchul.park@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox