From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Doug Smythies <dsmythies@telus.net>,
"'Thomas Ilsche'" <thomas.ilsche@tu-dresden.de>
Cc: "'Peter Zijlstra'" <peterz@infradead.org>,
"'Linux PM'" <linux-pm@vger.kernel.org>,
"'Frederic Weisbecker'" <fweisbec@gmail.com>,
"'Thomas Gleixner'" <tglx@linutronix.de>,
"'Paul McKenney'" <paulmck@linux.vnet.ibm.com>,
"'Rik van Riel'" <riel@surriel.com>,
"'Aubrey Li'" <aubrey.li@linux.intel.com>,
"'Mike Galbraith'" <mgalbraith@suse.de>,
"'LKML'" <linux-kernel@vger.kernel.org>
Subject: Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework
Date: Sun, 18 Mar 2018 12:00:44 +0100 [thread overview]
Message-ID: <2043615.lCdO10SMaB@aspire.rjw.lan> (raw)
In-Reply-To: <001a01d3be0a$ad3a0ed0$07ae2c70$@net>
On Saturday, March 17, 2018 5:11:53 PM CET Doug Smythies wrote:
> On 2018.03.17 Thomas Ilsche wrote:
>
> > Over the last week I tested v4+pollv2 and now v5+pollv3. With v5, I
> > observe a particular idle behavior, that I have not seen before with
> > v4. On a dual-socket Skylake system the idle power increases from
> > 74.1 W (system total) to 85.5 W with a 300 HZ build and even to
> > 138.3 W with a 1000 HZ build. A similar Haswell-EP system is also
> > affected.
>
> I confirm your idle findings. There is a regression between V4 and V5.
> The differences on my test computer are much less than on yours,
> probably because I have only 8 CPUs.
>
> http://fast.smythies.com/rjw_idle.png
>
> 1000 Hz kernel only.
Doug, Thomas,
Thank you both for the reports, much appreciated!
Below is a drop-in v6 replacement for patch [4/7].
With this new patch applied instead of the [4/7] the behavior should be much
more in line with the v4 behavior, so please try it if you can and let me know
if that really is the case on your systems.
Patches [5-7/7] from the original v5 apply on top of it right away for me,
but I've also created a git branch you can use to pull all of the series
with the below included:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
idle-loop
Thanks!
---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: [PATCH v6] cpuidle: Return nohz hint from cpuidle_select()
Add a new pointer argument to cpuidle_select() and to the ->select
cpuidle governor callback to allow a boolean value indicating
whether or not the tick should be stopped before entering the
selected state to be returned from there.
Make the ladder governor ignore that pointer (to preserve its
current behavior) and make the menu governor return 'false" through
it if:
(1) the idle exit latency is constrained at 0,
(2) the selected state is a polling one, or
(3) the selected state is not deep enough.
Since the value returned through the new argument pointer is not
used yet, this change is not expected to alter the functionality of
the code.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v5 -> v6: Change tick stopping conditions in the menu governor to
be more in line with the v4 behavior.
---
drivers/cpuidle/cpuidle.c | 10 ++++++--
drivers/cpuidle/governors/ladder.c | 3 +-
drivers/cpuidle/governors/menu.c | 44 ++++++++++++++++++++++++++++++++-----
include/linux/cpuidle.h | 8 ++++--
kernel/sched/idle.c | 4 ++-
5 files changed, 57 insertions(+), 12 deletions(-)
Index: linux-pm/include/linux/cpuidle.h
===================================================================
--- linux-pm.orig/include/linux/cpuidle.h
+++ linux-pm/include/linux/cpuidle.h
@@ -135,7 +135,8 @@ extern bool cpuidle_not_available(struct
struct cpuidle_device *dev);
extern int cpuidle_select(struct cpuidle_driver *drv,
- struct cpuidle_device *dev);
+ struct cpuidle_device *dev,
+ bool *nohz_ret);
extern int cpuidle_enter(struct cpuidle_driver *drv,
struct cpuidle_device *dev, int index);
extern void cpuidle_reflect(struct cpuidle_device *dev, int index);
@@ -167,7 +168,7 @@ static inline bool cpuidle_not_available
struct cpuidle_device *dev)
{return true; }
static inline int cpuidle_select(struct cpuidle_driver *drv,
- struct cpuidle_device *dev)
+ struct cpuidle_device *dev, bool *nohz_ret)
{return -ENODEV; }
static inline int cpuidle_enter(struct cpuidle_driver *drv,
struct cpuidle_device *dev, int index)
@@ -250,7 +251,8 @@ struct cpuidle_governor {
struct cpuidle_device *dev);
int (*select) (struct cpuidle_driver *drv,
- struct cpuidle_device *dev);
+ struct cpuidle_device *dev,
+ bool *nohz_ret);
void (*reflect) (struct cpuidle_device *dev, int index);
};
Index: linux-pm/kernel/sched/idle.c
===================================================================
--- linux-pm.orig/kernel/sched/idle.c
+++ linux-pm/kernel/sched/idle.c
@@ -188,13 +188,15 @@ static void cpuidle_idle_call(void)
next_state = cpuidle_find_deepest_state(drv, dev);
call_cpuidle(drv, dev, next_state);
} else {
+ bool nohz = true;
+
tick_nohz_idle_stop_tick();
rcu_idle_enter();
/*
* Ask the cpuidle framework to choose a convenient idle state.
*/
- next_state = cpuidle_select(drv, dev);
+ next_state = cpuidle_select(drv, dev, &nohz);
entered_state = call_cpuidle(drv, dev, next_state);
/*
* Give the governor an opportunity to reflect on the outcome
Index: linux-pm/drivers/cpuidle/cpuidle.c
===================================================================
--- linux-pm.orig/drivers/cpuidle/cpuidle.c
+++ linux-pm/drivers/cpuidle/cpuidle.c
@@ -272,12 +272,18 @@ int cpuidle_enter_state(struct cpuidle_d
*
* @drv: the cpuidle driver
* @dev: the cpuidle device
+ * @nohz_ret: indication on whether or not to stop the tick
*
* Returns the index of the idle state. The return value must not be negative.
+ *
+ * The memory location pointed to by @nohz_ret is expected to be written the
+ * 'false' boolean value if the scheduler tick should not be stopped before
+ * entering the returned state.
*/
-int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
+ bool *nohz_ret)
{
- return cpuidle_curr_governor->select(drv, dev);
+ return cpuidle_curr_governor->select(drv, dev, nohz_ret);
}
/**
Index: linux-pm/drivers/cpuidle/governors/ladder.c
===================================================================
--- linux-pm.orig/drivers/cpuidle/governors/ladder.c
+++ linux-pm/drivers/cpuidle/governors/ladder.c
@@ -63,9 +63,10 @@ static inline void ladder_do_selection(s
* ladder_select_state - selects the next state to enter
* @drv: cpuidle driver
* @dev: the CPU
+ * @dummy: not used
*/
static int ladder_select_state(struct cpuidle_driver *drv,
- struct cpuidle_device *dev)
+ struct cpuidle_device *dev, bool *dummy)
{
struct ladder_device *ldev = this_cpu_ptr(&ladder_devices);
struct device *device = get_cpu_device(dev->cpu);
Index: linux-pm/drivers/cpuidle/governors/menu.c
===================================================================
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -275,12 +275,16 @@ again:
goto again;
}
+#define TICK_USEC_HZ ((USEC_PER_SEC + HZ/2) / HZ)
+
/**
* menu_select - selects the next idle state to enter
* @drv: cpuidle driver containing state data
* @dev: the CPU
+ * @nohz_ret: indication on whether or not to stop the tick
*/
-static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
+ bool *nohz_ret)
{
struct menu_device *data = this_cpu_ptr(&menu_devices);
struct device *device = get_cpu_device(dev->cpu);
@@ -303,8 +307,10 @@ static int menu_select(struct cpuidle_dr
latency_req = resume_latency;
/* Special case when user has set very strict latency requirement */
- if (unlikely(latency_req == 0))
+ if (unlikely(latency_req == 0)) {
+ *nohz_ret = false;
return 0;
+ }
/* determine the expected residency time, round up */
data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
@@ -354,6 +360,7 @@ static int menu_select(struct cpuidle_dr
if (latency_req > interactivity_req)
latency_req = interactivity_req;
+ expected_interval = TICK_USEC_HZ;
/*
* Find the idle state with the lowest power while satisfying
* our constraints.
@@ -367,17 +374,44 @@ static int menu_select(struct cpuidle_dr
continue;
if (idx == -1)
idx = i; /* first enabled state */
- if (s->target_residency > data->predicted_us)
+ if (s->target_residency > data->predicted_us) {
+ /*
+ * Retain the tick if the selected state is shallower
+ * than the deepest available one with target residency
+ * within the tick period range.
+ *
+ * This allows the tick to be stopped even if the
+ * predicted idle duration is within the tick period
+ * range to counter the effect by which the prediction
+ * may be skewed towards lower values due to the tick
+ * bias.
+ */
+ expected_interval = s->target_residency;
break;
- if (s->exit_latency > latency_req)
+ }
+ if (s->exit_latency > latency_req) {
+ /*
+ * If we break out of the loop for latency reasons,
+ * retain the tick unless the target residency of the
+ * selected state is too high.
+ */
+ expected_interval = drv->states[idx].target_residency;
break;
-
+ }
idx = i;
}
if (idx == -1)
idx = 0; /* No states enabled. Must use 0. */
+ /*
+ * Don't stop the tick if the selected state is a polling one or it is
+ * not deep enough.
+ */
+ if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) ||
+ expected_interval < TICK_USEC_HZ)
+ *nohz_ret = false;
+
data->last_state_idx = idx;
return data->last_state_idx;
next prev parent reply other threads:[~2018-03-18 11:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 21:59 Rafael J. Wysocki
2018-03-15 22:03 ` [RFT][PATCH v5 1/7] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-15 22:05 ` [RFT][PATCH v5 2/7] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-15 22:07 ` [RFT][PATCH v5 3/7] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-15 22:11 ` [RFT][PATCH v5 4/7] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-19 9:11 ` Peter Zijlstra
2018-03-19 9:39 ` Rafael J. Wysocki
2018-03-15 22:13 ` [RFT][PATCH v5 5/7] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-15 22:16 ` [RFT][PATCH v5 6/7] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-03-19 9:45 ` Peter Zijlstra
2018-03-19 9:49 ` Rafael J. Wysocki
2018-03-15 22:19 ` [RFT][PATCH v5 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick Rafael J. Wysocki
2018-03-19 12:47 ` Thomas Ilsche
2018-03-19 18:21 ` Doug Smythies
2018-03-20 17:15 ` Doug Smythies
2018-03-20 17:28 ` Rafael J. Wysocki
2018-03-17 12:42 ` [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Thomas Ilsche
2018-03-17 16:11 ` Doug Smythies
2018-03-18 11:00 ` Rafael J. Wysocki [this message]
2018-03-18 16:15 ` Rafael J. Wysocki
2018-03-19 10:49 ` Peter Zijlstra
2018-03-19 11:36 ` Rafael J. Wysocki
2018-03-19 11:58 ` Rafael J. Wysocki
2018-03-19 12:31 ` Peter Zijlstra
2018-03-20 10:01 ` Thomas Ilsche
2018-03-20 10:49 ` Rafael J. Wysocki
2018-03-20 17:15 ` Doug Smythies
2018-03-20 21:03 ` Doug Smythies
2018-03-21 6:33 ` Rafael J. Wysocki
2018-03-21 13:51 ` Doug Smythies
2018-03-21 13:58 ` Rafael J. Wysocki
2018-03-18 15:30 ` Doug Smythies
2018-03-18 16:06 ` 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=2043615.lCdO10SMaB@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=aubrey.li@linux.intel.com \
--cc=dsmythies@telus.net \
--cc=fweisbec@gmail.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
all inboxes | Powered by JetHome®