Re: [PATCH 3/3] sched: fair: Fix wrong idle timestamp usage

From: Daniel Lezcano
Date: Thu Apr 16 2015 - 04:47:06 EST


On 04/15/2015 07:10 PM, Morten Rasmussen wrote:
On Wed, Apr 15, 2015 at 04:43:17PM +0100, Daniel Lezcano wrote:
On 04/15/2015 02:18 PM, Peter Zijlstra wrote:
On Wed, Apr 15, 2015 at 12:00:24PM +0200, Daniel Lezcano wrote:
The find_idlest_cpu is assuming the rq->idle_stamp information reflects when
the cpu entered the idle state. This is wrong as the cpu may exit and enter
the idle state several times without the rq->idle_stamp being updated.

Sure, but you forgot to tell us why it matters.

Yes, right. Thanks for pointing this out.

Assuming we are in the situation where there are several idle cpus in
the same idle state.

With the current code, the function find_idlest_cpu will choose a cpu
with the shortest idle duration. This information is based on the
rq->idle_stamp variable and is correct until one of the idle cpu is
exiting the cpuidle_enter function and re-entering it again. As soon as
this happen, the rq->idle_stamp value is no longer a reliable information.

Example:

* CPU0 and CPU1 are running
* CPU2 and CPU3 are in the C3 state.
* CPU2 entered idle at T2
* CPU3 entered idle at T3
* T2 < T3

The function find_idlest_cpu will choose CPU3 because it has a shorter
idle duration.

Then CPU3 is woken up by an interrupt, process it and re-enter idle C3.

The information will still give the out to date information T2 < T3 and
find_idlest_cpu will choose CPU2 instead of CPU3.

I can't get the example to match your description of how
find_idlest_cpu() is supposed to work :-(

Did you mean CPU2 (not CPU3) getting woken up by an interrupt and
find_busiest_cpu() choosing CPU3 instead of CPU2 after the interrupt?

In your example find_busiest_cpu() should return CPU3 before the
interrupt as it went to sleep last and the interrupt on CPU3 should not
affect that choice as CPU3 is still the last cpu to go to sleep
(regardless of your patch). No?

Yes you are right. I meant CPU2 is woken up by the interrupt.


--
<http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/