linux-kernel - [PATCH v1 4/5] cpuidle: menu: Don't stay in shallow state for a long time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1534090171-14464-5-git-send-email-leo.yan@linaro.org>
Date:   Mon, 13 Aug 2018 00:09:30 +0800
From:   Leo Yan <leo.yan@...aro.org>
To:     "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Ramesh Thomas <ramesh.thomas@...el.com>,
        linux-kernel@...r.kernel.org, Linux PM <linux-pm@...r.kernel.org>
Cc:     Leo Yan <leo.yan@...aro.org>
Subject: [PATCH v1 4/5] cpuidle: menu: Don't stay in shallow state for a long time

To avoid staying in a shallow state for a long time, the menu governor
relies on not stopping tick when detects the prediction is shorter than
the tick event.  This is just luckily to cover most cases but cannot say
it is completely safe.  For example, if the prediction is 2000us and the
TICK_USEC=1000 so it's impossible to meet the condition
'data->predicted_us < TICK_USEC' and this lead to stop the tick for a
shallow state; finally the CPU is possible to stay in this shallow state
for very long time.

This patch checks the candidate idle state isn't deepest one and find if
the timer will come after more than 2 times of the maximum target
residency, though the governor selects a shallow state according to
prediction, due the timer is most reliable waken up source but it will
come very late, so the CPU has chance to stay in the shallow state
for a long time; the patch doesn't stop the tick for this case so can
avoid powernightmares issue.

Signed-off-by: Leo Yan <leo.yan@...aro.org>
---
 drivers/cpuidle/governors/menu.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 4f02207..566c65c 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -284,6 +284,10 @@ static unsigned int get_typical_interval(struct menu_device *data)
 static bool menu_decide_stopping_tick(struct cpuidle_driver *drv,
 				      struct menu_device *data, int idx)
 {
+	int max_target_residency;
+
+	max_target_residency = drv->states[drv->state_count-1].target_residency;
+
 	/*
 	 * If the tick has been stopped yet, force to stop it afterwards and
 	 * don't give chance to set *stop_tick to false.
@@ -302,6 +306,23 @@ static bool menu_decide_stopping_tick(struct cpuidle_driver *drv,
 	if (data->predicted_us < TICK_USEC)
 		return false;
 
+	/*
+	 * The candidate idle state isn't deepest one, on the other hand
+	 * the most reliable wakeup source is timer (compare against to
+	 * interrupts) says it will come after more than 2 times of maximum
+	 * target residency, this means the CPU has risk to stay in shallow
+	 * state for more than 2 times of maximum target residency.
+	 *
+	 * It's acceptable to stay in the shallow state at this time but we
+	 * need to ensure to wake up the CPU by tick to check if has better
+	 * choice.  Finally it can have choice to select deeper state and
+	 * avoid the CPU staying in shallow state for very long time and
+	 * without any wake up event.
+	 */
+	if (idx < drv->state_count - 1 &&
+	    data->next_timer_us > max_target_residency * 2)
+		return false;
+
 	/* Otherwise, let's stop the tick at this time. */
 	return true;
 }
-- 
2.7.4