linux-kernel - Re: [PATCH] sched/deadline: Add sched

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: <20140121135559.GK30183@twins.programming.kicks-ass.net>
Date:	Tue, 21 Jan 2014 14:55:59 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Luca Abeni <luca.abeni@...tn.it>
Cc:	Henrik Austad <henrik@...tad.us>,
	Juri Lelli <juri.lelli@...il.com>, tglx@...utronix.de,
	mingo@...hat.com, rostedt@...dmis.org, oleg@...hat.com,
	fweisbec@...il.com, darren@...art.com, johan.eker@...csson.com,
	p.faure@...tech.ch, linux-kernel@...r.kernel.org,
	claudio@...dence.eu.com, michael@...rulasolutions.com,
	fchecconi@...il.com, tommaso.cucinotta@...up.it,
	nicola.manica@...i.unitn.it, dhaval.giani@...il.com,
	hgu1972@...il.com, paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
	insop.song@...il.com, liming.wang@...driver.com, jkacur@...hat.com,
	harald.gustafsson@...csson.com, vincent.guittot@...aro.org,
	bruce.ashfield@...driver.com, rob@...dley.net
Subject: Re: [PATCH] sched/deadline: Add sched_dl documentation

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/