public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Bjoern Brandenburg <bbb@email.unc.edu>
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>,
	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: Fri, 09 Jul 2010 18:35:04 +0200	[thread overview]
Message-ID: <1278693304.1900.266.camel@laptop> (raw)
In-Reply-To: <51F8E441-58D7-45E1-B7A0-7A717EDF08B5@email.unc.edu>

On Fri, 2010-07-09 at 16:51 +0200, Bjoern Brandenburg wrote:
> On Jul 9, 2010, at 4:18 PM, Peter Zijlstra wrote:
> 
> > On Fri, 2010-07-09 at 15:38 +0200, Raistlin wrote:
> > 
> >> - using periods for calculating the tasks' bandwidth and then using   
> >>   deadlines for scheduling the tasks is going to work, but the
> >>   admission control test that you would need for ensuring anybody
> >>   will make its deadline is waaay more complex than Sum_i(BW_i)<1, even
> >>   for uniprocessors/partitionig. That one instead would gives you just
> >>   a very basic guarantee that the design in not completely broken
> >>   (formally, I think I should say it is only a necessary
> >>   condition :-)).
> > 
> > Happen to have a paper handy that explains all this in a concise way? 
> > 
> 
> Sounds confusing, but this is actually not that complicated.

Indeed, reading the referenced paper did clear things up, thanks!

I think the easiest path for now would indeed be to split between hard
and soft rt tasks, and limit hard to d==p, and later worry about
supporting d<p for hard.

It will very much depend on how we're going to go about doing things
with that 'load-balancer' thingy anyway.

The idea is that we approximate G-EDF by moving tasks around, but Dario
told me the admission tests are still assuming P-EDF.

Add to that the interesting problems of task affinity and we might soon
all have a head-ache ;-)

One thing we can do is limit the task affinity to either 1 cpu or all
cpus in the load-balance domain. Since there don't yet exist any
applications we can disallow things to make life easier.

If we only allow pinned tasks and free tasks, splitting the admission
test in two would suffice I think, if keep one per-cpu utilization
measure and use the maximum of these over all cpus to start the global
utilization measure, things ought to work out.

If we do hard and soft independenty, we would need to split those into 2
again, resulting in 4 sets of measures.





  reply	other threads:[~2010-07-09 16:35 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 [this message]
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
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=1278693304.1900.266.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