Re: report a bug about sched_rt

[Raistlin]

On Fri, 2009-07-24 at 18:01 +0200, Peter Zijlstra wrote:
> For bugs the throttle works, like I said a well functioning system is
> not supposed to hit the throttle, obviously a bug precludes the well
> functioning qualification :-)
> 
Yes, I also think a bandwidth isolation/throttling mechanism could help
a lot either with bugs or when you need hard real-time, soft real-time
and non real-time applications to live together in one single system
such as Linux is --or is about to become.

> Unpredictable calculation times can be dealt with on the application
> design level, for example using techniques such as outlined here:
> 
>   http://feanor.sssup.it/~faggioli/papers/OSPERT-2009-dlexception.pdf
> 
Thanks Peter! :-)

We're getting more citation in this ML than in 'our' academic world...
I'm not sure it is useful for our PhD and research career, but, indeed,
I like that very much anyway! :-P

The mechanism proposed in that paper is one way for providing developers
with the capability of specifying some typical real time "attributes" of
an application (or part of it), such as deadline and/or expected (worst
case?) execution time.

It is probably not always the best way of doing, but it's something we
think it could be useful somewhere. Therefore, we are still working on
it, e.g., improving timer resolution, adding the support for new
semantic and programming models, etc. Moreover, we are open to any
suggestion and contribution about this work, especially from the
community!

> These really are things you should know about before writing an RT
> application ;-)
:-D

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