Re: periods and deadlines in SCHED_DEADLINE

From: Raistlin
Date: Sat Jul 10 2010 - 17:52:51 EST


On Sat, 2010-07-10 at 22:08 +0200, Harald Gustafsson wrote:
> > That is a very delicate point, the whole reason SCHED_FIFO and friends
> > suck so much is that they don't provide any kind of isolation, and thus,
> > as an Operating-System abstraction they're an utter failure.
> >
> > If you take out admission control you end up with a similar situation.
>
> OK, I see your point, and I also want to keep the isolation, its just
> that I thought that the complexity might be too large to be accepted
> by mainline. Let's work towards a solution with good admission
> control, i.e. having more complex admission control to handle this.
>
Indeed. I think things might be done step by step, relaxing the
constraints as long as we find better solutions.

> > Embedded people can of course easily hack in whatever they well fancy,
> > and adding the 'yes_I_really_want_this_anyway' flag or even taking out
> > admission control all together is something the GPL allows them to do.
>
> Not an option I would like to pursue, it should be possible to get a
> working solution without this.
>
Yeah, I see your point and agree with it. Btw, I think that, even in the
configuration described by Peter, if you --as an embedded system
engineer-- have the full control of your device/product, you can avoid
having any hard-rt task. Then, if you only have soft ones, you'll get
the benefit of having the possibility of setting D!=P without suffering
of any interference... Am I right?

I think this could be a viable solution, at least until we have
something better to relax assumptions on the schedulability test for
hard tasks, isn't it?

Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)

http://blog.linux.it/raistlin / raistlin@xxxxxxxxx /
dario.faggioli@xxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part