Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754682AbaAUN4j (ORCPT ); Tue, 21 Jan 2014 08:56:39 -0500 Received: from merlin.infradead.org ([205.233.59.134]:55883 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754441AbaAUN4i (ORCPT ); Tue, 21 Jan 2014 08:56:38 -0500 Date: Tue, 21 Jan 2014 14:55:59 +0100 From: Peter Zijlstra To: Luca Abeni Cc: Henrik Austad , Juri Lelli , tglx@linutronix.de, mingo@redhat.com, rostedt@goodmis.org, oleg@redhat.com, fweisbec@gmail.com, darren@dvhart.com, johan.eker@ericsson.com, p.faure@akatech.ch, linux-kernel@vger.kernel.org, claudio@evidence.eu.com, michael@amarulasolutions.com, fchecconi@gmail.com, tommaso.cucinotta@sssup.it, nicola.manica@disi.unitn.it, dhaval.giani@gmail.com, hgu1972@gmail.com, paulmck@linux.vnet.ibm.com, raistlin@linux.it, insop.song@gmail.com, liming.wang@windriver.com, jkacur@redhat.com, harald.gustafsson@ericsson.com, vincent.guittot@linaro.org, bruce.ashfield@windriver.com, rob@landley.net Subject: Re: [PATCH] sched/deadline: Add sched_dl documentation Message-ID: <20140121135559.GK30183@twins.programming.kicks-ass.net> References: <1390214440-2711-1-git-send-email-juri.lelli@gmail.com> <20140120112442.GA8907@austad.us> <52DD1377.5090201@gmail.com> <20140120131616.GB8907@austad.us> <52DD2711.9080504@unitn.it> <20140121102016.GA12002@austad.us> <52DE5B7F.8020900@unitn.it> <20140121123334.GJ30183@twins.programming.kicks-ass.net> <52DE6D21.1080602@unitn.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52DE6D21.1080602@unitn.it> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 21, 2014 at 01:50:41PM +0100, Luca Abeni wrote: > On 01/21/2014 01:33 PM, Peter Zijlstra wrote: > >>- During the execution of a job, the task might invoke a blocking system call, > >> and block... When it wakes up, it is still in the same job (decoding the same > >> video frame), and not in a different one. > >>This is (IMHO) where all the confusion comes from. > > > >I would strongly urge you not to use that as an example, because its > >dead wrong design. An RT thread (be it RR,FIFO or DL) should _NEVER_ do > >blocking IO. > Well, but it does happen in reality :) Yeah, I know, my point was more about not encouraging people to do this by explicitly mentioning it. > On the other hand, I agree with you that a hard real-time task should be designed > not to do things like this. But SCHED_DEADLINE is flexible enough to be used on > many different kinds of tasks (hard real-time, soft real-time, etc...). At which point I feel obliged to mention the work Jim did on statistical bounded tardiness and a potential future option: SCHED_FLAG_DL_AVG_RUNTIME, where we would allow tasks to somewhat exceed their runtime budget provided that they meet their budget on average. A possible implementation could be to track the unused budget of previous instances and keep a decaying sum (such that we're guaranteed this unused budget < 2*runtime). And then allow runtime overruns upto this limit. Another possibly extension; one proposed by Ingo; is to demote tasks to SCHED_OTHER once they exceed their budget instead of the full block they get now -- we could possibly call this SCHED_FLAG_DL_CBS_SOFT or such. And of course SCHED_FLAG_DL_CBS_SIGNAL, where the task gets a signal delivered if it exceeded the runtime -- I think some of the earlier patches had things like this, no? > >On the other subject; I wouldn't actually mind if it grew into a proper > >(academic or not) summary of deadline scheduling theory and how it > >applies. > > > >Sure, refer to actual papers for all the proofs and such, but it would > >be very good to go over all the bits and pieces that make up the system. > > > >So cover the periodic, sporadic and aperiodic model like henr_k > >suggested, please do cover the job/instance idiom as it is used all over > >the place. > Ok... My point was that it would be better (IMHO) to first explain how > sched_deadline works (and no notion of job/instance, etc is needed for this), > and then explain how this applies to the real-time task model (and here, of > course all the formal notation can be introduced). > > Do you think this can be reasonable? Sure, I think that's reasonable. > >Then also treat schedulability tests and their ramification, explain > >what laxity is, what tardiness is, that GEDF doesn't have 0 tardiness > >but does have bounded tardiness. > > > >Maybe even mention the actual bounds -- but refer to papers for their > >proofs. > > > >Mention CBS and the ramification etc.. > Ok. > I guess some of these details can be added incrementally, with additional > patches? Oh sure, all of this will always be a work in progress anyway ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/