All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.