From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, riel@redhat.com, mingo@kernel.org,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com,
sbw@mit.edu
Subject: Re: [PATCH RFC tip/core/rcu] Parallelize and economize NOCB kthread wakeups
Date: Thu, 3 Jul 2014 22:05:41 -0700 [thread overview]
Message-ID: <20140704050541.GL4603@linux.vnet.ibm.com> (raw)
In-Reply-To: <1404444236.5756.36.camel@marge.simpson.net>
On Fri, Jul 04, 2014 at 05:23:56AM +0200, Mike Galbraith wrote:
> On Thu, 2014-07-03 at 09:29 -0700, Paul E. McKenney wrote:
> > On Thu, Jul 03, 2014 at 07:48:40AM +0200, Mike Galbraith wrote:
> > > On Wed, 2014-07-02 at 22:21 -0700, Paul E. McKenney wrote:
> > > > On Thu, Jul 03, 2014 at 05:31:19AM +0200, Mike Galbraith wrote:
> > >
> > > > > NO_HZ_FULL is a property of a set of CPUs. isolcpus is supposed to go
> > > > > away as being a redundant interface to manage a single property of a set
> > > > > of CPUs, but it's perfectly fine for NO_HZ_FULL to add an interface to
> > > > > manage a single property of a set of CPUs. What am I missing?
> > > >
> > > > Well, for now, it can only be specified at build time or at boot time.
> > > > In theory, it is possible to change a CPU from being callback-offloaded
> > > > to not at runtime, but there would need to be an extremely good reason
> > > > for adding that level of complexity. Lots of "fun" races in there...
> > >
> > > Yeah, understood.
> > >
> > > (still it's a NO_HZ_FULL wart though IMHO, would be prettier and more
> > > usable if it eventually became unified with cpuset and learned how to
> > > tap-dance properly;)
> >
> > Agreed, it would in some sense be nice. What specifically do you need
> > it for?
>
> I personally have zero use for the thing (git/vi aren't particularly
> perturbation sensitive;). I'm just doing occasional drive-by testing
> from a distro perspective, how well does it work, what does it cost etc.
>
> > Are you really running workloads that generate large numbers of
> > callbacks spread across most of the CPUs? It was this sort of workload
> > that caused Rik's system to show scary CPU-time accumulation, due to
> > the high overhead of frequent one-to-many wakeups.
> >
> > If your systems aren't running that kind of high-callback-rate workload,
> > just set CONFIG_RCU_NOCB_CPU_ALL=y and don't worry about it.
> >
> > If your systems -are- running that kind of high-callback-rate workload,
> > but your system has fewer than 200 CPUs, ensure that you have enough
> > housekeeping CPUs to allow the grace-period kthread sufficient CPU time,
> > set CONFIG_RCU_NOCB_CPU_ALL=y and don't worry about it.
> >
> > If your systems -are- running that kind of high-callback-rate workload,
> > and your system has more than 200 CPUs, apply the following patch,
> > set CONFIG_RCU_NOCB_CPU_ALL=y and once again don't worry about it. ;-)
>
> Turn it on and don't worry about it is exactly what distros want the
> obscure feature with very few users to be. Last time I did a drive-by,
> my boxen said I should continue to worry about it ;-)
Yep, which is the reason for the patch on the last email.
Then again, exactly which feature and which reason for worry?
Thanx, Paul
next prev parent reply other threads:[~2014-07-04 5:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-27 14:20 [PATCH RFC tip/core/rcu] Parallelize and economize NOCB kthread wakeups Paul E. McKenney
2014-06-27 15:01 ` Mathieu Desnoyers
2014-06-27 15:13 ` Mathieu Desnoyers
2014-06-27 15:21 ` Paul E. McKenney
2014-06-27 15:19 ` Paul E. McKenney
2014-07-02 12:34 ` Peter Zijlstra
2014-07-02 13:46 ` Rik van Riel
2014-07-02 16:55 ` Paul E. McKenney
2014-07-03 2:53 ` Paul E. McKenney
2014-07-02 15:39 ` Paul E. McKenney
2014-07-02 16:04 ` Peter Zijlstra
2014-07-02 17:08 ` Paul E. McKenney
2014-07-02 17:26 ` Peter Zijlstra
2014-07-02 17:29 ` Rik van Riel
2014-07-02 17:57 ` Paul E. McKenney
2014-07-03 9:49 ` Peter Zijlstra
2014-07-02 17:55 ` Paul E. McKenney
2014-07-03 9:50 ` Peter Zijlstra
2014-07-08 13:19 ` Paul E. McKenney
2014-07-03 13:12 ` Peter Zijlstra
2014-07-08 13:44 ` Paul E. McKenney
2014-07-03 3:31 ` Mike Galbraith
2014-07-03 5:21 ` Paul E. McKenney
2014-07-03 5:48 ` Mike Galbraith
2014-07-03 16:29 ` Paul E. McKenney
2014-07-04 3:23 ` Mike Galbraith
2014-07-04 5:05 ` Paul E. McKenney [this message]
2014-07-04 6:01 ` Mike Galbraith
2014-07-04 21:20 ` Paul E. McKenney
2014-07-05 13:04 ` Frederic Weisbecker
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=20140704050541.GL4603@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=dvhart@linux.intel.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=niv@us.ibm.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
--cc=umgwanakikbuti@gmail.com \
/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