Messages in this thread | | | Date | Mon, 20 Aug 2018 13:02:54 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v5] cpuidle: menu: Handle stopped tick more aggressively |
| |
On Tue, Aug 14, 2018 at 12:34:40PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states > with stopped tick) missed the case when the target residencies of > deep idle states of CPUs are above the tick boundary which may cause > the CPU to get stuck in a shallow idle state for a long time. > > Say there are two CPU idle states available: one shallow, with the > target residency much below the tick boundary and one deep, with > the target residency significantly above the tick boundary. In > that case, if the tick has been stopped already and the expected > next timer event is relatively far in the future, the governor will > assume the idle duration to be equal to TICK_USEC and it will select > the idle state for the CPU accordingly. However, that will cause the > shallow state to be selected even though it would have been more > energy-efficient to select the deep one. > > To address this issue, modify the governor to always use the time > till the closest timer event instead of the predicted idle duration > if the latter is less than the tick period length and the tick has > been stopped already. Also make it extend the search for a matching > idle state if the tick is stopped to avoid settling on a shallow > state if deep states with target residencies above the tick period > length are available. > > In addition, make it always indicate that the tick should be stopped > if it has been stopped already for consistency. > > 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>
Seems OK,
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
| |