Re: [RFC][PATCH 18/22] sched: add reclaiming logic to -deadlinetasks

[Raistlin]

On Thu, 2010-11-11 at 23:12 +0100, Peter Zijlstra wrote:
> > Therefore, this patch:
> >  - adds the flags for specyfing DEADLINE, RT or OTHER reclaiming
> >    behaviour;
> >  - adds the logic that changes the scheduling class of a task when
> >    it overruns, according to the requested policy.
> 
> The first two definitely should require SYS_CAP_ADMIN because it allows
> silly while(1) loops again.. 
>
Sure, good point!

> but can we postpone this fancy feature as
> well? 
> 
As you wish, I'll keep backing it in my private tree...

> I'd much rather have the stochastic thing implemented that allows
> limited temporal overrun.
>
... But at this point I can't avoid asking. That model aims at _pure_
hard real-time scheduling *without* resource reservation capabilities,
provided it deals with temporal overruns by means of a probabilistic
analysis, right?
In this scheduler, we do have resource reservations to deal with
overruns, provided it can guarantee bandwidth isolation among tasks even
in case of overrun (which is very typical soft real-time solution, but
can provide hard guarantees as well, if the analysis is careful enough).

Are we sure the two approaches matches, and/or can live together?

That's because I'm not sure what we would do, at that point, while
facing a runtime overrun... Enforce the bandwidth by stopping the task
until its next deadline (as we do now)? Or allows it to overrun basing
of the statistical information we have? Or do we want somehow try to do
both?

I know we can discuss and decide the details later, after merging all
this... But I still think it's worth trying to have at least a basic
idea of how to do that, just to avoid doing something now that we will
regret then. :-)

Thanks,
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