From: Raistlin <raistlin@linux.it>
To: Bjoern Brandenburg <bbb@email.unc.edu>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Song Yuan <song.yuan@ericsson.com>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Nicola Manica <nicola.manica@disi.unitn.it>,
Luca Abeni <lucabe72@email.it>,
Claudio Scordino <claudio@evidence.eu.com>,
Harald Gustafsson <harald.gustafsson@ericsson.com>,
bastoni@cs.unc.edu, Giuseppe Lipari <lipari@retis.sssup.it>
Subject: Re: periods and deadlines in SCHED_DEADLINE
Date: Sat, 10 Jul 2010 09:08:26 +0200 [thread overview]
Message-ID: <1278745706.4390.2.camel@Palantir> (raw)
In-Reply-To: <51F8E441-58D7-45E1-B7A0-7A717EDF08B5@email.unc.edu>
[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]
On Fri, 2010-07-09 at 16:51 +0200, Bjoern Brandenburg wrote:
> > Happen to have a paper handy that explains all this in a concise way?
> >
>
> Sounds confusing, but this is actually not that complicated.
>
> - If the period exceeds the deadline of a task, then it is said to have a constrained deadline, and is said to be a constrained task.
>
> - The density of a task is the ratio budget/min(period, relative deadline). The density of a task is at most its utilization (budget/period).
>
> - There exists a simple *sufficient* (but not necessary) test for uniprocessor EDF for constrained tasks: if the sum of all task densities is at most one (on each processor), then all jobs will meet their deadlines. (Of course, this assumes that the budget is only replenished at the beginning at each period and does not take self-suspensions due to I/O etc. into account.)
>
Right, I think Bjoern made it much more clear than how you can find it
in many of the existing papers! :-)
Just to make a simple UP example, if you have two tasks with the
following parameters (where T_i=(C_i, P_i, D_i)):
T_1 = (4, 10, 5)
T_2 = (4, 10, 5)
Then the test Sum_i(C_i/P_i)<1 will say "go!" (4/10+4/10<1), but
one of the tasks can miss its deadline by 3 time units in the worst case
(if, and if yes which one, depends on the order with witch they arrive).
Using D_i instead of P_i in the test will make things better in this
case (4/5+4/5>1 ==> "no go!"), but its overly pessimistic (i.e., only
sufficient). In fact for this task set:
T_1 = (1, 10, 2)
T_2 = (2, 20, 4)
T_3 = (3, 50, 6)
which has small utilization (Sum_i(C_i/P_i)=.26) and *is schedulable*,
even if 1/2+2/4+3/6=1.5>1.
Hope this helped in clarifying things even more! :-D
Btw, another nice survey about schedulability tests for global EDF I
know (and you'll forgive me if I point you to something from my
institution :-)) is this http://retis.sssup.it/~marko/papers/ICPP09.pdf.
> As a side note, almost all global EDF hard real-time admission tests can handle tasks with constrained deadlines transparently. However, as far as I can tell, they do not apply to SCHED_DEADLINE.
>
This is the only part I am not sure I got... Can you explain me what do
you mena by "they do not apply" ?
> PS: My responses will be delayed, I'm off to the airport...
>
Yep, so will be mine one, including this one! :-P
Thanks and regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
http://blog.linux.it/raistlin / raistlin@ekiga.net /
dario.faggioli@jabber.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-07-10 7:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-09 13:38 periods and deadlines in SCHED_DEADLINE Raistlin
2010-07-09 14:18 ` Peter Zijlstra
2010-07-09 14:51 ` Bjoern Brandenburg
2010-07-09 16:35 ` Peter Zijlstra
2010-07-10 9:01 ` Raistlin
2010-07-10 10:28 ` Peter Zijlstra
2010-07-10 14:49 ` Raistlin
2010-07-11 6:42 ` Bjoern Brandenburg
2010-08-03 9:41 ` Peter Zijlstra
2010-08-04 3:52 ` Andrea Bastoni
2010-08-04 7:14 ` Peter Zijlstra
2010-08-04 5:18 ` Bjoern Brandenburg
2010-08-03 9:46 ` Peter Zijlstra
2010-08-04 3:53 ` Andrea Bastoni
2010-08-04 5:02 ` Bjoern Brandenburg
2010-07-10 7:08 ` Raistlin [this message]
2010-07-11 6:46 ` Bjoern Brandenburg
2010-08-03 8:16 ` Peter Zijlstra
2010-08-03 11:42 ` Gregory Haskins
2010-08-04 6:30 ` Bjoern Brandenburg
2010-07-09 14:24 ` Peter Zijlstra
2010-07-10 7:11 ` Luca Abeni
2010-07-10 10:36 ` Peter Zijlstra
2010-07-11 6:12 ` Bjoern Brandenburg
2010-07-09 14:30 ` Peter Zijlstra
2010-07-10 9:14 ` Raistlin
2010-07-10 17:19 ` Harald Gustafsson
2010-07-10 18:31 ` Peter Zijlstra
2010-07-10 20:08 ` Harald Gustafsson
2010-07-10 21:52 ` Raistlin
2010-07-11 5:41 ` Harald Gustafsson
2010-07-11 7:32 ` Bjoern Brandenburg
2010-07-12 10:21 ` Harald Gustafsson
2010-08-04 5:55 ` Bjoern Brandenburg
2010-08-02 19:34 ` Peter Zijlstra
2010-08-04 4:44 ` Bjoern Brandenburg
2010-07-09 14:32 ` Peter Zijlstra
2010-07-10 7:50 ` Raistlin
2010-07-10 15:11 ` Peter Zijlstra
2010-07-10 17:29 ` Harald Gustafsson
2010-07-11 6:15 ` Bjoern Brandenburg
2010-07-10 7:09 ` Luca Abeni
2010-07-10 9:20 ` Raistlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1278745706.4390.2.camel@Palantir \
--to=raistlin@linux.it \
--cc=bastoni@cs.unc.edu \
--cc=bbb@email.unc.edu \
--cc=claudio@evidence.eu.com \
--cc=dmitry.adamushko@gmail.com \
--cc=harald.gustafsson@ericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lipari@retis.sssup.it \
--cc=lucabe72@email.it \
--cc=nicola.manica@disi.unitn.it \
--cc=peterz@infradead.org \
--cc=song.yuan@ericsson.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox