Re: [PATCH 18/18 v2] sched/fair: Take into account slice in EAS

[Kayra Cizmeci]

Hi Tim,

>                             struct task_struct *p)
>  {
>         unsigned long task_slice = p->se.slice;
> +       bool target_first = task_slice < get_rq_min_slice(cpu_rq(target->cpu));
> +       bool min_first = task_slice < get_rq_min_slice(cpu_rq(min->cpu));
>
> -       /*  Select the one where you can run first */
> -        if (task_slice < get_rq_min_slice(cpu_rq(target->cpu)) &&
> -           task_slice >= get_rq_min_slice(cpu_rq(min->cpu)))
> -               return true;
> +       /*
> +        * Select the one where you can run first. Check both ways, or the
> +        * result depends on the order of the CPUs in the PD.
> +        */
> +       if (target_first != min_first)
> +               return target_first;
>
>        /* Favor previous CPU */
>        if (target->cpu == prev)

> Take an idle CPU X and a busy prev_cpu. Any task can
> run first on X, because an empty rq has min_slice == ULONG_MAX:

> - prev_cpu scanned first: when X is the target, the slice check
>   selects X.
> - X scanned first: when prev_cpu is the target, the slice check fails,
>   and "Favor previous CPU" then selects prev_cpu.

> In the second case the task is stacked on the busy prev_cpu even though
> it may not run first there.

Agreed. 

But ULONG_MAX doesn't always means that the rq is empty.
(See my 18/4 review, maybe I'm getting something wrong)

Also, I assume prev == min-cpu.

Scene:

target is X, min is prev, prev has a 5 ms sliced task while X is empty and task_slice = 4
target_first comes true and min_first comes true they're equal and min is chosen.

If however, the task_slice was bigger or equal to 5, as correctly target would be chosen.

LGTM atleast. Eh. (ULONG_MAX could be a problem tho.)

Thanks, 
Kayra