From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Byungchul Park <byungchul.park@lge.com>,
jiangshanlai@gmail.com, josh@joshtriplett.org,
mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org,
kernel-team@lge.com, joel@joelfernandes.org
Subject: Re: [RFC 1/2] rcu: Do prepare and cleanup idle depending on in_nmi()
Date: Wed, 20 Jun 2018 09:30:11 -0700 [thread overview]
Message-ID: <20180620163011.GV3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180620121156.4da98db2@gandalf.local.home>
On Wed, Jun 20, 2018 at 12:11:56PM -0400, Steven Rostedt wrote:
> On Wed, 20 Jun 2018 08:56:58 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > OK, so in theory this change is safe from a tracing perspective. But
> > it does add conditionals to a fastpath.
>
> Does it?
>
> I see it replacing two conditions from both rcu_irq_enter/exit() with a
> single one in rcu_nmi_enter/exit(). Sure it adds one to rcu_nmi_enter()
> but that's a far less fast path than rcu_irq_enter(), which this patch
> removes a conditional from.
Fair point. But I am still a bit nervous about the in_nmi(). That
could be avoided by an argument to rcu_nmi_enter() and rcu_nmi_exit()
(or common-code functions derived from these), and the usual inlining
should eliminate both the argument and the check from generated code.
However, it is also the case that the original invokes
rcu_dynticks_task_exit() before the rcu_dynticks_eqs_exit() and
rcu_cleanup_after_idle() afterwards, and the new code executes them
both afterwards. Why is this transformation safe?
Thanx, Paul
prev parent reply other threads:[~2018-06-20 16:28 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 8:47 [RFC 1/2] rcu: Do prepare and cleanup idle depending on in_nmi() Byungchul Park
2018-06-20 8:47 ` [RFC 2/2] rcu: Remove ->dynticks_nmi_nesting from struct rcu_dynticks Byungchul Park
2018-06-20 14:58 ` Paul E. McKenney
2018-06-20 16:05 ` Byungchul Park
2018-06-20 16:49 ` Paul E. McKenney
2018-06-20 17:15 ` Byungchul Park
2018-06-20 17:40 ` Paul E. McKenney
2018-06-21 6:39 ` Byungchul Park
2018-06-21 6:48 ` Byungchul Park
2018-06-21 10:08 ` Byungchul Park
2018-06-21 15:05 ` Paul E. McKenney
2018-06-21 15:04 ` Paul E. McKenney
2018-06-22 3:00 ` Byungchul Park
2018-06-22 13:36 ` Paul E. McKenney
2018-06-22 5:56 ` Joel Fernandes
2018-06-22 13:28 ` Paul E. McKenney
2018-06-22 14:19 ` Andy Lutomirski
2018-06-22 16:12 ` Paul E. McKenney
2018-06-22 16:01 ` Steven Rostedt
2018-06-22 18:14 ` Paul E. McKenney
2018-06-22 18:19 ` Joel Fernandes
2018-06-22 18:32 ` Steven Rostedt
2018-06-22 20:05 ` Joel Fernandes
2018-06-25 8:28 ` Byungchul Park
2018-06-25 16:39 ` Joel Fernandes
2018-06-25 17:19 ` Paul E. McKenney
2018-06-25 19:15 ` Joel Fernandes
2018-06-25 20:25 ` Steven Rostedt
2018-06-25 20:47 ` Paul E. McKenney
2018-06-25 20:47 ` Andy Lutomirski
2018-06-25 22:16 ` Steven Rostedt
2018-06-25 23:30 ` Andy Lutomirski
2018-06-25 22:15 ` Steven Rostedt
2018-06-25 23:32 ` Andy Lutomirski
2018-06-25 21:25 ` Joel Fernandes
2018-06-22 20:58 ` Paul E. McKenney
2018-06-22 20:58 ` Paul E. McKenney
2018-06-22 21:00 ` Steven Rostedt
2018-06-22 21:16 ` Paul E. McKenney
2018-06-22 22:03 ` Andy Lutomirski
2018-06-23 17:53 ` Paul E. McKenney
2018-06-28 20:02 ` Paul E. McKenney
2018-06-28 21:13 ` Joel Fernandes
2018-06-28 21:41 ` Paul E. McKenney
2018-06-23 15:48 ` Joel Fernandes
2018-06-23 17:56 ` Paul E. McKenney
2018-06-24 3:02 ` Joel Fernandes
2018-06-20 13:33 ` [RFC 1/2] rcu: Do prepare and cleanup idle depending on in_nmi() Steven Rostedt
2018-06-20 14:58 ` Paul E. McKenney
2018-06-20 15:25 ` Byungchul Park
2018-06-20 14:50 ` Paul E. McKenney
2018-06-20 15:43 ` Steven Rostedt
2018-06-20 15:56 ` Paul E. McKenney
2018-06-20 16:11 ` Byungchul Park
2018-06-20 16:14 ` Steven Rostedt
2018-06-20 16:37 ` Byungchul Park
2018-06-20 16:11 ` Steven Rostedt
2018-06-20 16:30 ` Paul E. McKenney [this message]
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=20180620163011.GV3593@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=byungchul.park@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kernel-team@lge.com \
--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