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

[Tim Chen <tim.c.chen@linux.intel.com>]

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