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, dhowells@redhat.com, edumazet@google.com,
darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu
Subject: Re: [PATCH tip/core/rcu 0/9] sysidle changes for v3.12
Date: Sat, 17 Aug 2013 20:13:41 -0700 [thread overview]
Message-ID: <20130818031341.GK28923@leaf> (raw)
In-Reply-To: <20130818014918.GA27827@linux.vnet.ibm.com>
On Sat, Aug 17, 2013 at 06:49:18PM -0700, Paul E. McKenney wrote:
> Hello!
>
> Whenever there is at least one non-idle CPU, it is necessary to
> periodically update timekeeping information. Before NO_HZ_FULL, this
> updating was carried out by the scheduling-clock tick, which ran on
> every non-idle CPU. With the advent of NO_HZ_FULL, it is possible
> to have non-idle CPUs that are not receiving scheduling-clock ticks.
> This possibility is handled by assigning a timekeeping CPU that continues
> taking scheduling-clock ticks.
>
> Unfortunately, timekeeping CPU continues taking scheduling-clock
> interrupts even when all other CPUs are completely idle, which is
> not so good for energy efficiency and battery lifetime. Clearly, it
> would be good to turn off the timekeeping CPU's scheduling-clock tick
> when all CPUs are completely idle. This is conceptually simple, but
> we also need good performance and scalability on large systems, which
> rules out implementations based on frequently updated global counts of
> non-idle CPUs as well as implementations that frequently scan all CPUs.
> Nevertheless, we need a single global indicator in order to keep the
> overhead of checking acceptably low.
>
> The chosen approach is to enforce hysteresis on the non-idle to
> full-system-idle transition, with the amount of hysteresis increasing
> linearly with the number of CPUs, thus keeping contention acceptably low.
> This approach piggybacks on RCU's existing force-quiescent-state scanning
> of idle CPUs, which has the advantage of avoiding the scan entirely on
> busy systems that have high levels of multiprogramming. This scan
> takes per-CPU idleness information and feeds it into a state machine
> that applies the level of hysteresis required to arrive at a single
> full-system-idle indicator.
>
> The individual patches are as follows:
>
> 1. Eliminate unused APIs that were intended for adaptive ticks.
>
> 2. Add documentation covering the testing of nohz_full.
>
> 3. Add a CONFIG_NO_HZ_FULL_SYSIDLE Kconfig parameter to enable
> this feature. Kernels built with CONFIG_NO_HZ_FULL_SYSIDLE=n
> act exactly as they do today.
>
> 4. Add new fields to the rcu_dynticks structure that track CPU-idle
> information. These fields consider CPUs running usermode to be
> non-idle, in contrast with the existing fields in that structure.
>
> 5. Track per-CPU idle states.
>
> 6. Add full-system idle states and state variables.
>
> 7. Expand force_qs_rnp(), dyntick_save_progress_counter(), and
> rcu_implicit_dynticks_qs() APIs to enable passing full-system
> idle state information.
>
> 8. Add full-system-idle state machine.
>
> 9. Force RCU's grace-period kthreads onto the timekeeping CPU.
Comments on 4, 5, and 6; for 1-3 and 7-9,
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
prev parent reply other threads:[~2013-08-18 3:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-18 1:49 [PATCH tip/core/rcu 0/9] sysidle changes for v3.12 Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 1/9] rcu: Eliminate unused APIs intended for adaptive ticks Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 2/9] nohz_full: Add testing information to documentation Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 3/9] nohz_full: Add Kconfig parameter for scalable detection of all-idle state Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 4/9] nohz_full: Add rcu_dyntick data " Paul E. McKenney
2013-08-18 3:02 ` Josh Triplett
2013-08-19 1:22 ` Paul E. McKenney
2013-08-19 1:34 ` Josh Triplett
2013-08-18 1:49 ` [PATCH tip/core/rcu 5/9] nohz_full: Add per-CPU idle-state tracking Paul E. McKenney
2013-08-18 3:04 ` Josh Triplett
2013-08-18 1:49 ` [PATCH tip/core/rcu 6/9] nohz_full: Add full-system idle states and variables Paul E. McKenney
2013-08-18 3:09 ` Josh Triplett
2013-08-19 1:39 ` Paul E. McKenney
2013-08-19 2:49 ` Josh Triplett
2013-08-19 3:32 ` Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 7/9] nohz_full: Add full-system-idle arguments to API Paul E. McKenney
2013-08-18 3:11 ` Josh Triplett
2013-08-19 1:50 ` Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 8/9] nohz_full: Add full-system-idle state machine Paul E. McKenney
2013-08-18 1:49 ` [PATCH tip/core/rcu 9/9] nohz_full: Force RCU's grace-period kthreads onto timekeeping CPU Paul E. McKenney
2013-08-18 3:13 ` Josh Triplett [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=20130818031341.GK28923@leaf \
--to=josh@joshtriplett.org \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.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=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;
as well as URLs for NNTP newsgroup(s).