linux-kernel - Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle

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]

Message-ID: <24df5e07-8a6b-26d9-6024-d6caa90c18de@oracle.com>
Date:   Mon, 5 Feb 2018 14:32:47 -0800
From:   Subhra Mazumdar <subhra.mazumdar@...cle.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Steven Sistare <steven.sistare@...cle.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...hat.com,
        dhaval.giani@...cle.com, tim.c.chen@...ux.intel.com
Subject: Re: [RESEND RFC PATCH V3] sched: Improve scalability of
 select_idle_sibling using SMT balance



On 02/05/2018 09:03 AM, Peter Zijlstra wrote:
> On Mon, Feb 05, 2018 at 01:48:54PM +0100, Peter Zijlstra wrote:
>> So while I see the point of tracking these numbers (for SMT>2), I don't
>> think its worth doing outside of the core, and then we still need some
>> powerpc (or any other architecture with abysmal atomics) tested.
> FWIW Power has another 'fun' feature, their cores have asymmetric SMT.
>
> Their cores have a static power level, based on _which_ SMT sibling is
> running, not how many. A single SMT2 runs (much) slower than a single
> SMT0.
>
> So that random selection stuff really doesn't work well for them. Now
> 'sadly' x86 can also have ASYM_PACKING set on its SMT domain, so I'm
> going to have to figure out what to do about all that.
Even the existing code doesn't handle that. The SMT balancing compares 
the remaining SMT capacity so even with asymmetric cores should work OK.

Thanks,
Subhra