Re: [RFC PATCH v3 00/16] Core scheduling v3

From: Tim Chen
Date: Thu Aug 08 2019 - 12:39:49 EST


On 8/8/19 5:55 AM, Aaron Lu wrote:
> On Mon, Aug 05, 2019 at 08:55:28AM -0700, Tim Chen wrote:
>> On 8/2/19 8:37 AM, Julien Desfossez wrote:
>>> We tested both Aaron's and Tim's patches and here are our results.

>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 26fea68f7f54..542974a8da18 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3888,7 +3888,7 @@ next_class:;
> WARN_ON_ONCE(!rq_i->core_pick);
>
> if (is_idle_task(rq_i->core_pick) && rq_i->nr_running)
> - rq->core_forceidle = true;
> + rq_i->core_forceidle = true;

Good catch!

>
> rq_i->core_pick->core_occupation = occ;
>
> With this fixed and together with the patch to let schedule always
> happen, your latest 2 patches work well for the 10s cpuhog test I
> described previously:
> https://lore.kernel.org/lkml/20190725143003.GA992@aaronlu/

That's encouraging. You are talking about my patches
that try to keep the force idle time between sibling threads
balanced, right?

>
> overloaded workload without any cpu binding doesn't work well though, I
> haven't taken a closer look yet.
>

I think we need a load balancing scheme among the cores that will try
to minimize force idle.

One possible metric to measure load compatibility imbalance that leads to
force idle is

Say i, j are sibling threads of a cpu core
imbalanace = \sum_tagged_cgroup abs(Load_cgroup_cpui - Load_cgroup_cpuj)

This gives us a metric to decide if migrating a task will improve
load compatability imbalance. As we already track cgroup load on a CPU,
it should be doable without adding too much overhead.

Tim