linux-kernel - Re: [RFD] sched/deadline: Support single CPU affinity

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: <d8f4ed40-af18-846f-2b85-351f5c81d0be@sssup.it>
Date:   Thu, 15 Dec 2016 12:30:43 +0100
From:   Tommaso Cucinotta <tommaso.cucinotta@...up.it>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Juri Lelli <juri.lelli@...il.com>,
        Luca Abeni <luca.abeni@...tn.it>,
        Steven Rostedt <rostedt@...dmis.org>,
        Claudio Scordino <claudio@...dence.eu.com>,
        Daniel Bistrot de Oliveira <danielbristot@...il.com>,
        Henrik Austad <henrik@...tad.us>, linux-kernel@...r.kernel.org
Subject: Re: [RFD] sched/deadline: Support single CPU affinity

Hi Peter,

On 13/12/2016 11:21, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 11:01:59AM +0100, Tommaso Cucinotta wrote:
>> Just a note: if you want to recover arbitrary task affinities, you can re-cast your above test like this:
>>
>> for_each_processor(cpu)
>>    \sum U[t]/A[t] \leq 1 (or U_max), for each task t on cpu, with utilization U[t] and A[t] tasks overall in its affinity mask
>>
> Do I read it correct when I interpret A[t] as the number of CPUs in its
> affinity mask?

yes, exactly, A[t] number of CPUs in the task affinity mask (sorry for my bad write-up)

> Also, does recoverable mean a bound tardiness, or is that something
> weaker still?

nope, nothing exact -- it just meant providing flexible but simple & consistent (ie, towards recovering affinity masks) options from the kernel/scheduler side, leaving more complex & exact tests to user-space, or future add-ons to the kernel.

Thanks,

     T.