From: Peter Zijlstra <peterz@infradead.org>
To: Luca Abeni <lucabe72@email.it>
Cc: Raistlin <raistlin@linux.it>,
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>,
Claudio Scordino <claudio@evidence.eu.com>,
Harald Gustafsson <harald.gustafsson@ericsson.com>,
Bjoern Brandenburg <bbb@email.unc.edu>,
bastoni@cs.unc.edu, Giuseppe Lipari <lipari@retis.sssup.it>
Subject: Re: periods and deadlines in SCHED_DEADLINE
Date: Sat, 10 Jul 2010 12:36:14 +0200 [thread overview]
Message-ID: <1278758174.1998.31.camel@laptop> (raw)
In-Reply-To: <1278745907.5248.18.camel@localhost>
On Sat, 2010-07-10 at 09:11 +0200, Luca Abeni wrote:
> On Fri, 2010-07-09 at 16:24 +0200, Peter Zijlstra wrote:
> > On Fri, 2010-07-09 at 15:38 +0200, Raistlin wrote:
> > > Basically, from the scheduling point of view, what it could happen is
> > > that I'm still _NOT_ going to allow a task with runtime Q_i, deadline
> > > D_i and period P_i to use more bandwidth than Q_i/P_i, I'm still using D
> > > for scheduling but the passing of the simple in-kernel admission test
> > > Sum_i(Q_i/P_i)<1 won't guarantee that the task will always finish its
> > > jobs before D.
> >
> > But the tardiness would still be bounded, right? So its a valid Soft-RT
> > model?
> I think that if Sum_i(Q_i/P_i)<1 but Sum_i(Q_i/min{P_i,D_i})>=1 then you
> can have sporadic deadline misses, but it should still be possible to
> compute an upper bound for the tardiness.
> But this is just a feeling, I have no proof... :)
The paper referenced by Bjoern yesterday mentioned that Baruah et al.
did that proof.
"For the considered case di < pi , Baruah et al. [7] showed
that the complexity increases considerably. However, as-
suming the processor utilization to be strictly less than 1,
Baruah et al. [6, 7] proved that if a deadline is missed,
this happens within a maximum time upper bound which
can be computed."
[6] S. Baruah, A. Mok, and L. Rosier. Preemptively scheduling
hard-real-time sporadic tasks on one processor. Proceedings
of the 11th IEEE Real-Time Systems Symposium, December 1990.
[7] S. Baruah, L. Rosier, and R. Howell. Algorithms and
complexity concerning the preemptive scheduling of peri-
odic real-time tasks on one processor. Real-Time Systems,
2(4):301–324, November 1990.
It also jives well with that I remember from reading through Jim's
papers on Soft-RT G-EDF.
next prev parent reply other threads:[~2010-07-10 10:36 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
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 [this message]
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=1278758174.1998.31.camel@laptop \
--to=peterz@infradead.org \
--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=raistlin@linux.it \
--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