linux-kernel - Re: [PATCH] sched: Introduce scaled capacity awareness in enqueue

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 for Android: free password hash cracker in your pocket

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

Message-ID: <63736e6f-37e6-e287-a920-56ab0d0586b7@oracle.com>
Date:   Wed, 31 May 2017 15:19:46 -0700
From:   Rohit Jain <rohit.k.jain@...cle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, mingo@...hat.com,
        vincent.guittot@...aro.org, morten.rasmussen@....com,
        dietmar.eggemann@....com
Subject: Re: [PATCH] sched: Introduce scaled capacity awareness in enqueue

On 05/30/2017 05:28 AM, Peter Zijlstra wrote:
> On Mon, May 22, 2017 at 01:48:14PM -0700, Rohit Jain wrote:
>> The patch introduces capacity awarness in scheduler (CAS) which avoids
>> CPUs which might have their capacities reduced (due to IRQ/RT activity)
>> when trying to schedule threads (on the push side) in the system. This
>> awareness has been added into the fair scheduling class.
>>
>> It does so by, using the following algorithm:
>> --------------------------------------------------------------------------
>> 1) As in rt_avg the scaled capacities are already calculated.
>>
>> 2) This scaled capacity is normalized and mapped into buckets.
> Why?

This is done to deterministically define the CPUs which are low on
capacities. By mapping it into buckets it becomes easier to do a
percentile calculation.

>> 3) Any CPU which lies below the 80th percentile in terms of percentage
>> capacity available is considered as a low capacity CPU.
> Random number; can we do better? What does existing code do?
>

Existing code checks to see if the waker is running on a CPU with better
capacity than the 'previous cpu'. If that is the case the waker cpu is
provided as 'target' to select_idle_sibling. (When I say capacity this
is not the scaled one because of IRQ, RT, etc.)

However, in case this 'target' is not an idle CPU, the rest of
select_idle_sibling would ignore the capacities altogether.