Re: periods and deadlines in SCHED_DEADLINE

[Peter Zijlstra]

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.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/