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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Sep 2019 10:13:22 -0700
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Aaron Lu <aaron.lu@...ux.alibaba.com>
Cc:     Vineeth Remanan Pillai <vpillai@...italocean.com>,
        Julien Desfossez <jdesfossez@...italocean.com>,
        Dario Faggioli <dfaggioli@...e.com>,
        "Li, Aubrey" <aubrey.li@...ux.intel.com>,
        Aubrey Li <aubrey.intel@...il.com>,
        Subhra Mazumdar <subhra.mazumdar@...cle.com>,
        Nishanth Aravamudan <naravamudan@...italocean.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paul Turner <pjt@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Frédéric Weisbecker <fweisbec@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Greg Kerr <kerrnel@...gle.com>, Phil Auld <pauld@...hat.com>,
        Valentin Schneider <valentin.schneider@....com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [RFC PATCH v3 00/16] Core scheduling v3

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