From: Leo Yan <leo.yan@linaro.org>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Ramesh Thomas <ramesh.thomas@intel.com>,
linux-kernel@vger.kernel.org, Linux PM <linux-pm@vger.kernel.org>
Cc: Leo Yan <leo.yan@linaro.org>
Subject: [PATCH v1 1/5] cpuidle: menu: Clean up variables usage in menu_select()
Date: Mon, 13 Aug 2018 00:09:27 +0800 [thread overview]
Message-ID: <1534090171-14464-2-git-send-email-leo.yan@linaro.org> (raw)
In-Reply-To: <1534090171-14464-1-git-send-email-leo.yan@linaro.org>
The usage for two variables 'data->predicted_us' and 'expected_interval'
in menu_select() are confused, especially these two variables are
assigned with each other: firstly 'data->predicted_us' is assigned to
the minimum value between 'data->predicted_us' and 'expected_interval',
so it presents the prediction period for taking account different
factors and include consideration for expected interval; but later
'data->predicted_us' is assigned back to 'expected_interval' and from
then on the function uses 'expected_interval' to select idle state; this
results in 'expected_interval' has two different semantics between the
top half and the bottom half of the same function.
This patch is to clean up the usage of these two variables, we always
use 'data->predicted_us' to present the idle duration predictions and
it can be used to compare with idle state target residency or tick
boundary for choosing idle state; we purely use 'expected_interval' to
record the expected interval value, which is mainly for interval
interrupt estimation.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
| 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 5eb7d6f..b972db1 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -363,7 +363,6 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
latency_req = interactivity_req;
select:
- expected_interval = data->predicted_us;
/*
* Find the idle state with the lowest power while satisfying
* our constraints.
@@ -386,7 +385,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
* expected idle duration so that the tick is retained
* as long as that target residency is low enough.
*/
- expected_interval = drv->states[idx].target_residency;
+ data->predicted_us = drv->states[idx].target_residency;
break;
}
idx = i;
@@ -400,7 +399,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
* expected idle duration is shorter than the tick period length.
*/
if (((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) ||
- expected_interval < TICK_USEC) && !tick_nohz_tick_stopped()) {
+ data->predicted_us < TICK_USEC) && !tick_nohz_tick_stopped()) {
unsigned int delta_next_us = ktime_to_us(delta_next);
*stop_tick = false;
--
2.7.4
next prev parent reply other threads:[~2018-08-12 16:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-12 16:09 [PATCH v1 0/5] Improvement stopping tick decision making in 'menu' idle governor Leo Yan
2018-08-12 16:09 ` Leo Yan [this message]
2018-08-21 8:32 ` [PATCH v1 1/5] cpuidle: menu: Clean up variables usage in menu_select() Rafael J. Wysocki
2018-08-12 16:09 ` [PATCH v1 2/5] cpuidle: menu: Record tick delta value in struct menu_device Leo Yan
2018-08-21 8:34 ` Rafael J. Wysocki
2018-08-12 16:09 ` [PATCH v1 3/5] cpuidle: menu: Provide menu_decide_stopping_tick() Leo Yan
2018-08-12 16:09 ` [PATCH v1 4/5] cpuidle: menu: Don't stay in shallow state for a long time Leo Yan
2018-08-21 8:35 ` Rafael J. Wysocki
2018-08-12 16:09 ` [PATCH v1 5/5] cpuidle: menu: Change to compare prediction with tick delta Leo Yan
2018-08-21 8:37 ` [PATCH v1 0/5] Improvement stopping tick decision making in 'menu' idle governor 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=1534090171-14464-2-git-send-email-leo.yan@linaro.org \
--to=leo.yan@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=ramesh.thomas@intel.com \
--cc=vincent.guittot@linaro.org \
/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).