linux-kernel - Re: [PATCH RFC 5/5] sched/fair: remove impossible condition from find_idlest_group

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:   Mon, 30 Oct 2017 09:19:03 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Brendan Jackman <brendan.jackman@....com>,
        Dietmar <dietmar.eggemann@....com>,
        "Cc: Srinivas Pandruvada" <srinivas.pandruvada@...ux.intel.com>,
        "Cc: Len Brown" <lenb@...nel.org>,
        "Cc: Rafael J. Wysocki" <rjw@...ysocki.net>,
        "Cc: Viresh Kumar" <viresh.kumar@...aro.org>,
        "Cc: Juri Lelli" <juri.lelli@....com>,
        "Cc: Patrick Bellasi" <patrick.bellasi@....com>,
        "Cc: Steve Muckle" <smuckle@...gle.com>,
        "Cc: Chris Redpath" <Chris.Redpath@....com>,
        "Cc: Atish Patra" <atish.patra@...cle.com>,
        "Cc: Morten Ramussen" <morten.rasmussen@....com>,
        "Cc: Frederic Weisbecker" <fweisbec@...il.com>,
        "Cc: Thomas Gleixner" <tglx@...utronix.de>,
        "Cc: EAS Dev" <eas-dev@...ts.linaro.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>
Subject: Re: [PATCH RFC 5/5] sched/fair: remove impossible condition from find_idlest_group_cpu

Hi Vincent,

On Mon, Oct 30, 2017 at 9:00 AM, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> On 28 October 2017 at 11:59, Joel Fernandes <joelaf@...gle.com> wrote:
>> find_idlest_group_cpu goes through CPUs of a group previous selected by
>> find_idlest_group. find_idlest_group returns NULL if the local group is the
>> selected one and doesn't execute find_idlest_group_cpu if the group to which
>> 'cpu' belongs to is chosen. So we're always guaranteed to call
>> find_idlest_group_cpu with a group to which cpu is non-local. This makes one of
>
> Is this still true in case of overlapping topology ?

Yes, I believe so. As per the code, find_idlest_group will only return
a group to which this_cpu doesn't belong to. So incase an overlapping
group was returned by find_idlest_group (instead of NULL), then none
of the groups (among the set of overlapping groups) is local to
this_cpu. Incase NULL is returned, then find_idlest_group_cpu doesn't
execute at all.

Do you agree?

thanks,

- Joel

[..]