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: <20161110153413.6900aa2b@sweethome>
Date:   Thu, 10 Nov 2016 15:34:13 +0100
From:   luca abeni <luca.abeni@...tn.it>
To:     Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Juri Lelli <juri.lelli@...il.com>,
        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,
        "al.biondi@...up.it" <al.biondi@...up.it>
Subject: Re: [RFD] sched/deadline: Support single CPU affinity

On Thu, 10 Nov 2016 12:03:47 +0100
Tommaso Cucinotta <tommaso.cucinotta@...up.it> wrote:

> On 10/11/2016 10:06, luca abeni wrote:
> > is equivalent to the "least laxity first" (LLF) algorithm.
> > Giving precedence to tasks with 0 laxity is a technique that is
> > often used to improve the schedulability on multi-processor
> > systems.  
> 
> EDZL (EDF / Zero Laxity first), right?
Yes, basically all the "ZL" algorithms (EDZL, but I think I've also
seen something like RMZL or similar).

> AFAICR, there's quite a lot of
> analysis on EDZL for multi-cores... eg, Insik Shin et al....
> 
>    http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6374195
Yes, this is why I mentined the 0-laxity thing... Of course, here the
situation is different (there are tasks that can be migrated, and tasks
that cannot), but maybe the 0-laxity analysis can be adapted to this
case?


> But, before going the EDZL way, isn't it worthwhile to consider
> just splitting tasks among 2 cpus
> 
>    https://people.mpi-sws.org/~bbb/papers/pdf/rtss16b.pdf
Yes, there are many possible different strategies that can be tested (I
think somewhere I saw some semi-partitioned algorithm that was even
optimal). I suspect everything depends on the trade-off between
implementation complexity and scheduling efficiency.



				Luca


> 
> ? ... we're working at RETIS on simpler ways to make the AC for
> these split tasks cases (cc-ing Alessandro) that doesn't need
> demand-bound complex analysis...
> 
> My2c,
> 
> 	T.