public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: luca abeni <luca.abeni@unitn.it>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Juri Lelli <juri.lelli@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: Bug in AC?
Date: Tue, 17 May 2016 23:30:27 +0200	[thread overview]
Message-ID: <20160517233027.611559c5@utopia> (raw)
In-Reply-To: <20160517103300.2cf6e28e@gandalf.local.home>

On Tue, 17 May 2016 10:33:00 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 17 May 2016 16:07:49 +0200
> luca abeni <luca.abeni@unitn.it> wrote:
> 
> > > As I
> > > mentioned on IRC, what about the case with two CPUs and this:
> > > 
> > > Two tasks with:       R:10us D: 15us P:100us
> > > and two tasks with:   R:6us  D: 14us P:14us
> > > 
> > > If the period of the first two tasks line up on two different CPUs
> > > then there's no way the other two tasks will make their deadlines.    
> > I agree this taskset is not schedulable on 2 CPUs. The problem is that
> > it is possible to generate tasksets with sum of densities < 2 that are
> > not schedulable on 2 CPUs.  
> 
> Makes sense. Thus the case is that we can't guarantee it on SMP anyway,
> so why put the extra effort to use deadline instead of period, where on
> UP we can make those guarantees.

My understanding (but, again, I might be wrong) is that periods are used
because the admission control based on periods (sum of utilisations
smaller than a given value) has a clear meaning (if the admission control
is passed, than I know that at least a specified percentage of CPU time is
left for non-deadline tasks).
On the other hand, the meaning on the admission control based on deadlines
is clear only on UP (on SMP, the fact that the admission control is passed
does not guarantee anything in particular - at least, it does not guarantee
anything more than the period-based admission control).



			Luca
> 
> I was under the impression that it appeared everyone was saying that SMP
> we can guarantee it and UP we could not, which is where I was confused.
> 
> -- Steve

  reply	other threads:[~2016-05-17 21:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160517090201.GA10196@pablo>
     [not found] ` <20160517123854.7204d206@utopia>
2016-05-17 13:46   ` Bug in AC? Steven Rostedt
2016-05-17 14:07     ` luca abeni
2016-05-17 14:33       ` Steven Rostedt
2016-05-17 21:30         ` luca abeni [this message]
2016-05-17 21:17     ` luca abeni

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=20160517233027.611559c5@utopia \
    --to=luca.abeni@unitn.it \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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