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

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

On 8/7/19 1:58 AM, Dario Faggioli wrote:

> So, here comes my question: I've done a benchmarking campaign (yes,
> I'll post numbers soon) using this branch:
> 
> https://github.com/digitalocean/linux-coresched.git  vpillai/coresched-v3-v5.1.5-test
> https://github.com/digitalocean/linux-coresched/tree/vpillai/coresched-v3-v5.1.5-test
> 
> Last commit:
> 7feb1007f274 "Fix stalling of untagged processes competing with tagged
> processes"
> 
> Since I see that, in this thread, there are various patches being
> proposed and discussed... should I rerun my benchmarks with them
> applied? If yes, which ones? And is there, by any chance, one (or maybe
> more than one) updated git branch(es)?
> 
> Thanks in advance and Regards
> 

Hi Dario,

Having an extra set of eyes are certainly welcomed.
I'll give my 2 cents on the issues with v3.
Others feel free to chime in if my understanding is
incorrect or I'm missing something.

1) Unfairness between the sibling threads
-----------------------------------------
One sibling thread could be suppressing and force idling
the sibling thread over proportionally.  Resulting in
the force idled CPU not getting run and stall tasks on
suppressed CPU.

Status:
i) Aaron has proposed a patchset here based on using one
rq as a base reference for vruntime for task priority
comparison between siblings.

https://lore.kernel.org/lkml/20190725143248.GC992@aaronlu/
It works well on fairness but has some initialization issues

ii) Tim has proposed a patchset here to account for forced
idle time in rq's min_vruntime
https://lore.kernel.org/lkml/f96350c1-25a9-0564-ff46-6658e96d726c@linux.intel.com/
It improves over v3 with simpler logic compared to
Aaron's patch, but does not work as well on fairness

iii) Tim has proposed yet another patch to maintain fairness
of forced idle time between CPU threads per Peter's suggestion.
https://lore.kernel.org/lkml/21933a50-f796-3d28-664c-030cb7c98431@linux.intel.com/
Its performance has yet to be tested.

2) Not rescheduling forced idled CPU
------------------------------------
The forced idled CPU does not get a chance to re-schedule
itself, and will stall for a long time even though it
has eligible tasks to run.

Status:
i) Aaron proposed a patch to fix this to check if there
are runnable tasks when scheduling tick comes in.
https://lore.kernel.org/lkml/20190725143344.GD992@aaronlu/

ii) Vineeth has patches to this issue and also issue 1, based
on scheduling in a new "forced idle task" when getting forced
idle, but has yet to post the patches.

3) Load balancing between CPU cores
-----------------------------------
Say if one CPU core's sibling threads get forced idled
a lot as it has mostly incompatible tasks between the siblings,
moving the incompatible load to other cores and pulling
compatible load to the core could help CPU utilization.

So just considering the load of a task is not enough during
load balancing, task compatibility also needs to be considered.
Peter has put in mechanisms to balance compatible tasks between
CPU thread siblings, but not across cores.

Status:
I have not seen patches on this issue.  This issue could lead to
large variance in workload performance based on your luck
in placing the workload among the cores.

Thanks.

Tim