Date: Thu, 10 Nov 2016 15:34:13 +0100
From: luca abeni <luca.abeni@unitn.it>
To: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Juri Lelli <juri.lelli@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Claudio Scordino <claudio@evidence.eu.com>,
        Daniel Bistrot de Oliveira <danielbristot@gmail.com>,
        Henrik Austad <henrik@austad.us>, linux-kernel@vger.kernel.org,
        "al.biondi@sssup.it" <al.biondi@sssup.it>
Subject: Re: [RFD] sched/deadline: Support single CPU affinity
Message-ID: <20161110153413.6900aa2b@sweethome>
In-Reply-To: <03a30c9c-eb42-c5c6-b94d-3a62048d8642@sssup.it>
References: <20161110080807.GD11311@worktop.programming.kicks-ass.net>
        <20161110100602.2781af72@sweethome>
        <03a30c9c-eb42-c5c6-b94d-3a62048d8642@sssup.it>
Organization: university of trento
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1499
Lines: 45

On Thu, 10 Nov 2016 12:03:47 +0100
Tommaso Cucinotta <tommaso.cucinotta@sssup.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.