[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160517233027.611559c5@utopia>
Date: Tue, 17 May 2016 23:30:27 +0200
From: luca abeni <luca.abeni@...tn.it>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Juri Lelli <juri.lelli@....com>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: Bug in AC?
On Tue, 17 May 2016 10:33:00 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> On Tue, 17 May 2016 16:07:49 +0200
> luca abeni <luca.abeni@...tn.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
Powered by blists - more mailing lists