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

[Tim Chen]

On 9/13/19 7:15 AM, Aaron Lu wrote:
> On Thu, Sep 12, 2019 at 10:29:13AM -0700, Tim Chen wrote:

> 
>> The better thing to do is to move one task from cgroupA to another core,
>> that has only one cgroupA task so it can be paired up
>> with that lonely cgroupA task.  This will eliminate the forced idle time
>> for cgropuA both on current core and also the migrated core.
> 
> I'm not sure if this is always possible.

During update_sg_lb_stats, we can scan for opportunities where pulling a task
from a source cpu in the sched group to the target dest cpu can reduce the forced idle imbalance.
And we also prevent task migrations that increase forced idle imbalance.

With those policies in place, we may not achieve perfect balance, but at least
we will load balance in the right direction to lower forced idle imbalance.

> 
> Say on a 16cores/32threads machine, there are 3 cgroups, each has 16 cpu
> intensive tasks, will it be possible to make things perfectly balanced?
> 
> Don't get me wrong, I think this kind of load balancing is good and
> needed, but I'm not sure if we can always make things perfectly
> balanced. And if not, do we care those few cores where cgroup tasks are
> not balanced and then, do we need to implement the core_wide cgoup
> fairness functionality or we don't care since those cores are supposed
> to be few and isn't a big deal?

Yes, we still need core wide fairness for tasks.  Load balancing is to
move tasks around so we will have less imbalance of cgroup tasks in a core
that results in forced idle time.  Once they are in place, we still need
to maintain fairness in a core.

Tim