Re: RFC for a new Scheduling policy/class in the Linux-kernel

[Raistlin <raistlin@linux.it>]

[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]

On Mon, 2009-07-13 at 15:45 -0600, Chris Friesen wrote:
> > The only selling point for PIP has been the ability of a thread to
> > suspend itself while holding a lock, such as to wait for
> > completion of an I/O operation.
> 
> You're comparing a full-featured PI implementation with a stripped-down
> PP (priority protection, aka priority ceiling) approach.  In an
> apples-to-apples comparison, the selling point for PI vs PP is that
> under PIP the priority of the lock holder is automatically boosted only
> if necessary, and only as high as necessary.  On the other hand, PP
> requires code analysis to properly set the ceilings for each individual
> mutex.
> 
I think I agree with this.

Moreover, talking about server/group based scheduling and considering
BWI/PEP, which are natural extensions of PI, you get the very nice
property of being independent from the actual knowledge of the blocking
time(s): you can run your scheduling test only considering the bandwidth
assigned to each component... And this is, at least for now and as far
as I know, not possible if you go for preventivate-blocking approaches
like P(C)P or SRP, and also for BROE or SIRAP I think.

I mean, if you only want to be sure to isolate applications and/or
components among themselves, without any knowledge of the blocking times
and critical section access patterns of the task running inside such
components, you can do it! Just pick up the bandwidths and see if they
fit with a scheduling test unmodified by any --very difficult to find
out, actually-- blocking term.
I know, this does not cover all the possible situations, and that it is
biased toward _soft_ real-time workloads, but I think it's a meaningful
use-case, especially considering Linux...

Anyway, it is more than possible that this belief is due to lack of
knowledge of mine about some other already existing solution... If so,
please, any pointer to it/them is more than welcome. :-)

> > Regarding the notion of charging proxy execution to the budget of
> > the client task, I have grave concerns. It is already hard enough
> > to estimate the amount of budget that a real-time task requires,
> > without this additional complication.  
> 
> Agreed.
> 
Well, indeed, I agre with this as well... But it yields the, to me, very
nice property described above (and in the other e-mail).

However, I'm light year far from proposing it as the "solutions for all
evils"! I know that, for instance, overhead and code twisting are severe
issues. The all I hope is to be able and have the time to give it a try,
and try to guess if it is worth. :-D

Regards again,
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@ekiga.net /
dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]