From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Christoph Lameter <cl@gentwo.org>,
linux-kernel@vger.kernel.org, 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,
peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com,
edumazet@google.com, dvhart@linux.intel.com, oleg@redhat.com,
sbw@mit.edu
Subject: Re: [PATCH tip/core/rcu 11/17] rcu: Bind grace-period kthreads to non-NO_HZ_FULL CPUs
Date: Fri, 11 Jul 2014 13:35:13 -0700 [thread overview]
Message-ID: <20140711203513.GA10652@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140711191113.GI26045@localhost.localdomain>
On Fri, Jul 11, 2014 at 09:11:15PM +0200, Frederic Weisbecker wrote:
> On Fri, Jul 11, 2014 at 02:05:08PM -0500, Christoph Lameter wrote:
> > On Fri, 11 Jul 2014, Frederic Weisbecker wrote:
> >
> > > > That would imply that all no-nohz processors are housekeeping? So all
> > > > processors with a tick are housekeeping?
> > >
> > > Well, now that I think about it again, I would really like to keep housekeeping
> > > to CPU 0 when nohz_full= is passed.
> >
> > Yeah.
> >
> > > > Could we make that set configurable? Ideally I'd like to have the ability
> > > > restrict the housekeeping to one processor.
> > >
> > > Ah, I'm curious about your usecase. But I think we can do that. And we should.
> >
> > The use case is pretty straightforward because we are trying to keep as
> > much OS noise as possible off most processors. Processor 0 is the
> > sacrificial lamb that will be used for all OS processing and hopefully all
> > high latency operations will occur there. Processors 1-X have a tick but
> > we still try to keep latencies sane. And then there is X-Y where tick is
> > off.
>
> Ok. I don't entirely get why you need 1-X but I can easily imagine some non-latency-critical
> stuff running there.
>
> Paul proposed "housekeeping=". If we ever go there, I'd rather vote for "sacrifical_lamb="
Given Christoph's desire for only one housekeeping CPU, I guess the
counting version makes the most sense, so that "housekeeping=N" designates
the first N non-nohz CPUs in numerical order as housekeeping CPUs.
If there are fewer than N non-nohz CPUs, you get a splat at boot time
and your request is capped at the number of non-nohz CPUs.
Seem reasonable?
Thanx, Paul
next prev parent reply other threads:[~2014-07-11 20:35 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-07 22:37 [PATCH tip/core/rcu 0/17] Miscellaneous fixes for 3.17 Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 01/17] rcu: Document deadlock-avoidance information for rcu_read_unlock() Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 02/17] rcu: Handle obsolete references to TINY_PREEMPT_RCU Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 03/17] signal: Explain local_irq_save() call Paul E. McKenney
2014-07-08 9:01 ` Lai Jiangshan
2014-07-08 15:50 ` Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 04/17] rcu: Make rcu node arrays static const char * const Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 05/17] rcu: remove redundant ACCESS_ONCE() from tick_do_timer_cpu Paul E. McKenney
2014-07-08 14:46 ` Frederic Weisbecker
2014-07-07 22:38 ` [PATCH tip/core/rcu 06/17] rcu: Eliminate read-modify-write ACCESS_ONCE() calls Paul E. McKenney
2014-07-08 16:59 ` Pranith Kumar
2014-07-08 20:35 ` Paul E. McKenney
2014-07-08 20:43 ` Pranith Kumar
2014-07-08 21:40 ` Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 07/17] rcu: Loosen __call_rcu()'s rcu_head alignment constraint Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 08/17] rcu: Allow post-unlock reference for rt_mutex Paul E. McKenney
2014-07-09 1:50 ` Lai Jiangshan
2014-07-09 16:04 ` Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 09/17] rcu: Check both root and current rcu_node when setting up future grace period Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 10/17] rcu: Simplify priority boosting by putting rt_mutex in rcu_node Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 11/17] rcu: Bind grace-period kthreads to non-NO_HZ_FULL CPUs Paul E. McKenney
2014-07-08 15:24 ` Frederic Weisbecker
2014-07-08 15:47 ` Paul E. McKenney
2014-07-08 18:38 ` Frederic Weisbecker
2014-07-08 19:58 ` Paul E. McKenney
2014-07-08 20:40 ` Frederic Weisbecker
2014-07-08 22:05 ` Paul E. McKenney
2014-07-09 15:40 ` Frederic Weisbecker
2014-07-11 18:10 ` Christoph Lameter
2014-07-11 18:25 ` Frederic Weisbecker
2014-07-11 18:45 ` Paul E. McKenney
2014-07-11 18:57 ` Frederic Weisbecker
2014-07-11 19:08 ` Paul E. McKenney
2014-07-11 19:26 ` Frederic Weisbecker
2014-07-11 19:43 ` Paul E. McKenney
2014-07-11 19:55 ` Frederic Weisbecker
2014-07-11 19:05 ` Christoph Lameter
2014-07-11 19:11 ` Frederic Weisbecker
2014-07-11 20:35 ` Paul E. McKenney [this message]
2014-07-11 20:45 ` Frederic Weisbecker
2014-07-12 1:39 ` Paul E. McKenney
2014-07-14 13:52 ` Christoph Lameter
2014-07-11 20:15 ` Peter Zijlstra
2014-07-14 13:53 ` Christoph Lameter
2014-07-11 18:29 ` Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 12/17] rcu: Don't use NMIs to dump other CPUs' stacks Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 13/17] rcu: Use __this_cpu_read() instead of per_cpu_ptr() Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 14/17] rcu: remove CONFIG_PROVE_RCU_DELAY Paul E. McKenney
2014-07-08 8:11 ` Paul Bolle
2014-07-08 13:56 ` Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 15/17] rcu: Fix __rcu_reclaim() to use true/false for bool Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 16/17] rcu: Fix a sparse warning in rcu_initiate_boost() Paul E. McKenney
2014-07-07 22:38 ` [PATCH tip/core/rcu 17/17] rcu: Fix a sparse warning in rcu_report_unblock_qs_rnp() Paul E. McKenney
2014-07-09 2:14 ` [PATCH tip/core/rcu 0/17] Miscellaneous fixes for 3.17 Lai Jiangshan
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=20140711203513.GA10652@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.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=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 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.