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

[Morten Rasmussen <morten.rasmussen@arm.com>]

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?

Morten