From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
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,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org,
alexei.starovoitov@gmail.com, daniel@iogearbox.net,
jolsa@redhat.com, bpf@vger.kernel.org
Subject: [PATCH RFC tip/core/rcu 0/4] Accelerate RCU Tasks Trace updates
Date: Thu, 10 Sep 2020 13:19:56 -0700 [thread overview]
Message-ID: <20200910201956.GA24190@paulmck-ThinkPad-P72> (raw)
Hello!
This series accelerates RCU Tasks Trace updates, reducing the average
grace-period latencies from about a second to about 20 milliseconds
on my x86 laptop. These are benchmark numbers, based on a previously
posted patch to rcuscale.c [1] running on my x86 laptop. The patches
in this series are as follows:
1. Mark variables static, noted during this effort but otherwise
unconnected. This change has no effect, so that the average
grace-period latency remains at 980 milliseconds.
2. Use more aggressive polling for RCU Tasks Trace. This polling
starts at five-millisecond intervals instead of the prior
100-millisecond intervals. As before, the polling interval
increases in duration as the grace period ages, and again as
before is capped at one second. This change reduces the
average grace-period latency to about 620 milliseconds.
3. Selectively enable more RCU Tasks Trace IPIs. This retains
the old behavior of suppressing IPIs for grace periods that are
younger than 500 milliseconds for CONFIG_TASKS_TRACE_RCU_READ_MB=y
kernels, including CONFIG_PREEMPT_RT=y kernels, but allows IPIs
immediately on other kernels. It is quite possible that a more
sophisticated decision procedure will be required, and changes
to RCU's dyntick-idle code might also be needed. This change
(along with the earlier ones) reduces the average grace-period
latency to about 120 milliseconds.
4. Shorten per-grace-period sleep for RCU Tasks Trace. The
current code sleeps for 100 milliseconds after the end of
each grace period, which by itself prevents a back-to-back
string of grace-period waits from completing faster than
ten per second. This patch also retains this old behavior
for CONFIG_TASKS_TRACE_RCU_READ_MB=y (and again thus also
for CONFIG_PREEMPT_RT=y kernels). For other kernels, this
post-grace-period sleep is reduced to five milliseconds.
This change (along with the earlier ones) reduced the average
grace-period latency to about 18 milliseconds, for an overall
factor-of-50 reduction in latency.
Alexei Starovoitov benchmarked an earlier patch [2], producing results
that are roughly consistent with the above reduction in latency [3].
Thanx, Paul
[1] https://lore.kernel.org/bpf/20200909193900.GK29330@paulmck-ThinkPad-P72/
[2] https://lore.kernel.org/bpf/20200910052727.GA4351@paulmck-ThinkPad-P72/
[3] https://lore.kernel.org/bpf/619554b2-4746-635e-22f3-7f0f09d97760@fb.com/
------------------------------------------------------------------------
tasks.h | 37 +++++++++++++++++++++++++++++--------
1 file changed, 29 insertions(+), 8 deletions(-)
next reply other threads:[~2020-09-10 20:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 20:19 Paul E. McKenney [this message]
2020-09-10 20:20 ` [PATCH RFC tip/core/rcu 1/4] rcu-tasks: Mark variables static paulmck
2020-09-10 20:20 ` [PATCH RFC tip/core/rcu 2/4] rcu-tasks: Use more aggressive polling for RCU Tasks Trace paulmck
2020-09-10 20:20 ` [PATCH RFC tip/core/rcu 3/4] rcu-tasks: Selectively enable more RCU Tasks Trace IPIs paulmck
2020-09-10 20:20 ` [PATCH RFC tip/core/rcu 4/4] rcu-tasks: Shorten per-grace-period sleep for RCU Tasks Trace paulmck
2020-09-11 3:18 ` Alexei Starovoitov
2020-09-11 4:37 ` Paul E. McKenney
2020-09-17 21:06 ` [PATCH RFC tip/core/rcu 0/4] Accelerate RCU Tasks Trace updates Paul E. McKenney
2020-09-17 21:07 ` [PATCH tip/core/rcu 1/8] rcu-tasks: Prevent complaints of unused show_rcu_tasks_classic_gp_kthread() paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 2/8] rcu-tasks: Mark variables static paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 3/8] rcu-tasks: Use more aggressive polling for RCU Tasks Trace paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 4/8] rcu-tasks: Selectively enable more RCU Tasks Trace IPIs paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 5/8] rcu-tasks: Shorten per-grace-period sleep for RCU Tasks Trace paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 6/8] rcu-tasks: Fix grace-period/unlock race in " paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 7/8] rcu-tasks: Fix low-probability task_struct leak paulmck
2020-09-17 21:07 ` [PATCH tip/core/rcu 8/8] rcu-tasks: Enclose task-list scan in rcu_read_lock() paulmck
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=20200910201956.GA24190@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=jolsa@redhat.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).