linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Thomas Ilsche <thomas.ilsche@tu-dresden.de>,
	Doug Smythies <dsmythies@telus.net>,
	Rik van Riel <riel@surriel.com>,
	Aubrey Li <aubrey.li@linux.intel.com>,
	Mike Galbraith <mgalbraith@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Len Brown <len.brown@intel.com>
Subject: [PATCH v9 00/10] sched/cpuidle: Idle loop rework
Date: Wed, 04 Apr 2018 10:32:12 +0200	[thread overview]
Message-ID: <1736751.LdhZHb50jq@aspire.rjw.lan> (raw)

Hi All,

Thanks a lot for the feedback so far!

For the motivation/summary, please refer to the BZ entry at

 https://bugzilla.kernel.org/show_bug.cgi?id=199227

created for collecting information related to this patch series.  Some v7.3
testing results from Len and Doug are in there already.

The testing so far shows significant idle power improvements, both in terms of
reducing the average idle power (about 10% on some systems) and in terms of
reducing the idle power noise (in the vast majority of cases, with this series
applied the idle power is mostly stable around the power floor of the system).
The average power is also reduced in some non-idle workloads and there are
some performance improvements in them.

It also is reported that the series generally addresses the problem it has been
motivated by (ie. the "powernightmares" issue).

This revision is mostly a re-send of the v8 with three patches changed as
follows.

> Patch 1 prepares the tick-sched code for the subsequent modifications and it
> doesn't change the code's functionality (at least not intentionally).
> 
> Patch 2 starts pushing the tick stopping decision deeper into the idle
> loop, but that is limited to do_idle() and tick_nohz_irq_exit().
> 
> Patch 3 makes cpuidle_idle_call() decide whether or not to stop the tick
> and sets the stage for the subsequent changes.
>
> Patch 4 is a new one just for the TICK_USEC definition changes.
>
> Patch 5 adds a bool pointer argument to cpuidle_select() and the ->select
> governor callback allowing them to return a "nohz" hint on whether or not to
> stop the tick to the caller.  It also adds code to decide what value to
> return as "nohz" to the menu governor and modifies its correction factor
> computations to take running tick into account if need be.
>
> Patch 6 (which is new) contains some changes that previously were included
> into the big reordering patch (patch [6/8] in the v7).  Essentially, it does
> more tick-sched code reorganization in preparation for the subsequent changes
> (and should not modify the functionality).

Patch 7 is a new version of its v8 counterpart.  It makes fewer changes to the
existing code and adds a special function for the handling of the use case it
is about.  It still makes some hrtimer code modifications allowing it to return
the time to the next event with one timer excluded (which needs to be done with
respect to the tick timer), though.

Patch 8 reorders the idle state selection with respect to the stopping of
the tick and causes the additional "nohz" hint from cpuidle_select() to be
used for deciding whether or not to stop the tick.  It is a rebased version
of its v8 counterpart.

Patch 9 causes the menu governor to refine the state selection in case the
tick is not going to be stopped and the already selected state does not fit
the interval before the next tick time.  It is a new version that avoids
using state 0 if it has been disabled (if state 0 has been disabled, the
governor only should use it when no states are enabled at all).

> Patch 10 Deals with the situation in which the tick was stopped previously,
> but the idle governor still predicts short idle (it has not changed).

This series is complementary to the poll_idle() patches discussed recently

https://patchwork.kernel.org/patch/10282237/
https://patchwork.kernel.org/patch/10311775/

that have been merged for v4.17 already.

There is a new git branch containing the current series at

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 idle-loop-v9

Thanks,
Rafael

             reply	other threads:[~2018-04-04  8:53 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04  8:32 Rafael J. Wysocki [this message]
2018-04-04  8:33 ` [PATCH v9 01/10] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-04-04  8:34 ` [PATCH v9 02/10] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-04-04  8:36 ` [PATCH v9 03/10] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-04-04  8:38 ` [PATCH v9 04/10] jiffies: Introduce USER_TICK_USEC and redefine TICK_USEC Rafael J. Wysocki
2018-04-06  1:09   ` Frederic Weisbecker
2018-04-06  7:20     ` Rafael J. Wysocki
2018-04-04  8:39 ` [PATCH v9 05/10] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-04-06  2:44   ` Frederic Weisbecker
2018-04-06  7:24     ` Rafael J. Wysocki
2018-04-06 14:19       ` Frederic Weisbecker
2018-04-06  7:58     ` Peter Zijlstra
2018-04-06 14:23       ` Frederic Weisbecker
2018-04-06  8:11     ` Rafael J. Wysocki
2018-04-06 12:56       ` Rafael J. Wysocki
2018-04-06 15:28         ` Frederic Weisbecker
2018-04-06 14:28       ` Frederic Weisbecker
2018-04-04  8:41 ` [PATCH v9 06/10] time: tick-sched: Split tick_nohz_stop_sched_tick() Rafael J. Wysocki
2018-04-07  2:36   ` Frederic Weisbecker
2018-04-07 16:36     ` Rafael J. Wysocki
2018-04-04  8:45 ` [PATCH v9 07/10] time: hrtimer: Introduce hrtimer_next_event_without() Rafael J. Wysocki
2018-04-07 14:46   ` Frederic Weisbecker
2018-04-08  8:20     ` Rafael J. Wysocki
2018-04-08 17:58       ` Frederic Weisbecker
2018-04-04  8:47 ` [PATCH v9 08/10] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-04-09  2:41   ` Frederic Weisbecker
2018-04-04  8:49 ` [PATCH v9 09/10] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-04-05 12:27   ` Peter Zijlstra
2018-04-05 13:51     ` Rafael J. Wysocki
2018-04-05 12:32   ` Peter Zijlstra
2018-04-05 13:52     ` Rafael J. Wysocki
2018-04-04  8:50 ` [PATCH v9 10/10] cpuidle: menu: Avoid selecting shallow states with stopped tick Rafael J. Wysocki
2018-04-05 12:47   ` Peter Zijlstra
2018-04-05 13:49     ` Rafael J. Wysocki
2018-04-05 14:11       ` Peter Zijlstra
2018-04-05 14:13         ` Peter Zijlstra
2018-04-05 14:29           ` Rafael J. Wysocki
2018-04-08 16:32 ` [PATCH v9 00/10] sched/cpuidle: Idle loop rework Rafael J. Wysocki
2018-04-09 15:58   ` Thomas Ilsche
2018-04-10  7:03     ` Rafael J. Wysocki

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=1736751.LdhZHb50jq@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=aubrey.li@linux.intel.com \
    --cc=dsmythies@telus.net \
    --cc=fweisbec@gmail.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgalbraith@suse.de \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.ilsche@tu-dresden.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).