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
