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

From: Rik van Riel
Date: Tue Jul 08 2014 - 23:07:53 EST

Hash: SHA1

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 <vincent.guittot@xxxxxxxxxx>

Acked-by: Rik van Riel <riel@xxxxxxxxxx>

- --
All rights reversed
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at