From: Josh Triplett <josh@joshtriplett.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, Valdis.Kletnieks@vt.edu,
dhowells@redhat.com, eric.dumazet@gmail.com, darren@dvhart.com,
fweisbec@gmail.com, sbw@mit.edu, patches@linaro.org
Subject: Re: [PATCH tip/core/rcu] Make RCU_FAST_NO_HZ respect nohz= boot parameter
Date: Thu, 5 Jul 2012 16:02:08 -0700 [thread overview]
Message-ID: <20120705230208.GB26150@leaf> (raw)
In-Reply-To: <20120705223731.GA27608@linux.vnet.ibm.com>
On Thu, Jul 05, 2012 at 03:37:31PM -0700, Paul E. McKenney wrote:
> If the nohz= boot parameter disables nohz, then RCU_FAST_NO_HZ needs to
> also disable itself. This commit therefore checks for tick_nohz_enabled
> being zero, disabling rcu_prepare_for_idle() if so. This patch assumes
> that tick_nohz_enabled can change at runtime: If this is not the case,
> then a simpler approach suffices.
Allowing nohz to change at runtime seems like an entirely unnecessary
bit of added complexity. (So does having a boot parameter for it, but
that one at least seems easier to handle.)
What would the patch look like if you can assume nohz will never change
at runtime? And does anyone have a use case for changing nohz at
runtime, rather than at boot time?
- Josh Triplett
next prev parent reply other threads:[~2012-07-05 23:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-05 22:37 [PATCH tip/core/rcu] Make RCU_FAST_NO_HZ respect nohz= boot parameter Paul E. McKenney
2012-07-05 23:02 ` Josh Triplett [this message]
2012-07-06 0:29 ` Paul E. McKenney
2012-07-06 3:46 ` Josh Triplett
2012-07-06 12: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=20120705230208.GB26150@leaf \
--to=josh@joshtriplett.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=eric.dumazet@gmail.com \
--cc=fweisbec@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=patches@linaro.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--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