Subject: [PATCH v3 02/12] sched: remove a wake_affine condition

From: [email-masked] (Rik van Riel)
Date: Tue, 08 Jul 2014 23:06:38 -0400

On 06/30/2014 12:05 PM, Vincent Guittot wrote:
> I have tried to understand the meaning of the condition : 
> (this_load <= load && this_load + target_load(prev_cpu, idx) <=
> tl_per_task) but i failed to find a use case that can take
> advantage of it and i haven't found clear description in the
> previous commits' log. Futhermore, the comment of the condition
> refers to the task_hot function that was used before being replaced
> by the current condition: /* * This domain has SD_WAKE_AFFINE and *
> p is cache cold in this domain, and * there is no bad imbalance. 
> */
> 
> If we look more deeply the below condition this_load +
> target_load(prev_cpu, idx) <= tl_per_task
> 
> When sync is clear, we have : tl_per_task = runnable_load_avg /
> nr_running this_load = max(runnable_load_avg, cpuload[idx]) 
> target_load =  max(runnable_load_avg', cpuload'[idx])
> 
> It implies that runnable_load_avg' == 0 and nr_running <= 1 in
> order to match the condition. This implies that runnable_load_avg
> == 0 too because of the condition: this_load <= load but if this
> _load is null, balanced is already set and the test is redundant.
> 
> If sync is set, it's not as straight forward as above (especially
> if cgroup are involved) but the policy should be similar as we have
> removed a task that's going to sleep in order to get a more
> accurate load and this_load values.
> 
> The current conclusion is that these additional condition don't
> give any benefit so we can remove them.
> 
> Signed-off-by: Vincent Guittot <[email-masked]>

Acked-by: Rik van Riel <[email-masked]>

- -- 
All rights reversed