From: leo.yan@linaro.org
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM <linux-pm@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Frederic Weisbecker <frederic@kernel.org>
Subject: Re: [PATCH] cpuidle: menu: Retain tick when shallow state is selected
Date: Wed, 22 Aug 2018 20:02:00 +0800 [thread overview]
Message-ID: <20180822120200.GA8949@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <34910476.pgRhNDWo5t@aspire.rjw.lan>
On Tue, Aug 21, 2018 at 10:44:10AM +0200, Rafael J . Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The case addressed by commit 5ef499cd571c (cpuidle: menu: Handle
> stopped tick more aggressively) in the stopped tick case is present
> when the tick has not been stopped yet too. Namely, if only two CPU
> idle states, shallow state A with target residency significantly
> below the tick boundary and deep state B with target residency
> significantly above it, are available and the predicted idle
> duration is above the tick boundary, but below the target residency
> of state B, state A will be selected and the CPU may spend indefinite
> amount of time in it, which is not quite energy-efficient.
>
> However, if the tick has not been stopped yet and the governor is
> about to select a shallow idle state for the CPU even though the idle
> duration predicted by it is above the tick boundary, it should be
> fine to wake up the CPU early, so the tick can be retained then and
> the governor will have a chance to select a deeper state when it runs
> next time.
>
> [Note that when this really happens, it will make the idle duration
> predictor believe that the CPU might be idle longer than predicted,
> which will make it more likely to predict longer idle durations going
> forward, but that will also cause deeper idle states to be selected
> going forward, on average, which is what's needed here.]
>
> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped tick)
> Reported-by: Leo Yan <leo.yan@linaro.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> Commit 5ef499cd571c (cpuidle: menu: Handle stopped tick more aggressively) is
> in linux-next only at this point.
>
> ---
> drivers/cpuidle/governors/menu.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> Index: linux-pm/drivers/cpuidle/governors/menu.c
> ===================================================================
> --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> +++ linux-pm/drivers/cpuidle/governors/menu.c
> @@ -379,9 +379,20 @@ static int menu_select(struct cpuidle_dr
> if (idx == -1)
> idx = i; /* first enabled state */
> if (s->target_residency > data->predicted_us) {
> - if (!tick_nohz_tick_stopped())
> + if (data->predicted_us < TICK_USEC)
With this change, for tick has been stopped, it might introduce
regression to select a shallow state and it's conflict with the effect
of patch "cpuidle: menu: Handle stopped tick more aggressively".
> break;
>
> + if (!tick_nohz_tick_stopped()) {
> + /*
> + * If the state selected so far is shallow,
> + * waking up early won't hurt, so retain the
> + * tick in that case and let the governor run
> + * again in the next iteration of the loop.
> + */
> + expected_interval = drv->states[idx].target_residency;
> + break;
> + }
> +
This is reliable, how we can rely on a shallow idle state target
residency to decide if need to stop a tick or not?
> /*
> * If the state selected so far is shallow and this
> * state's target residency matches the time till the
>
next prev parent reply other threads:[~2018-08-22 12:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 8:44 [PATCH] cpuidle: menu: Retain tick when shallow state is selected Rafael J. Wysocki
2018-08-22 12:02 ` leo.yan [this message]
2018-08-22 12:03 ` leo.yan
2018-08-22 21:01 ` Rafael J. Wysocki
2018-08-24 9:44 ` Rafael J. Wysocki
2018-08-24 15:44 ` Doug Smythies
2018-08-25 11:21 ` Rafael J. Wysocki
2018-08-26 19:37 ` Doug Smythies
2018-08-29 4:19 ` 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=20180822120200.GA8949@leoy-ThinkPad-X240s \
--to=leo.yan@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
/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