Re: report a bug about sched_rt

[Jamie Lokier <jamie@shareable.org>]

Peter Zijlstra wrote:
> On Fri, 2009-07-24 at 16:40 +0100, Jamie Lokier wrote:
> > Peter Zijlstra wrote:
> > > If you're using the bandwidth throttle to control your RT tasks so as
> > > not to starve your SCHED_OTHER tasks, then I will call your system ill
> > > designed.
> > 
> > What mechanism should be used to avoid starving SCHED_OTHER tasks, in
> > the event there are unforeseen bugs or unpredictable calculation times
> > in an RT task?
> 
> 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 :-)
> 
> 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
> 
> These really are things you should know about before writing an RT
> application ;-)

Certainly those things can be used, if you are really serious about RT
behaviour.  They are quite complex.

For simple things like "try to keep the buffer to my DVD writer full"
(no I don't know how much CPU that requires - it's a kind of "best
effort but try very hard!"), it would be quite useful to have
something like RT-bandwidth which grants a certain percentage of time
as an RT task, and effectively downgrades it to SCHED_OTHER when that
time is exceeded to permit some fairness with the rest of the system.

You can do that in userspace using the techniques in the PDF, and I
have looked at such techniques many years ago (2.2 days!), but the
same could be said about RT-bandwidth.  But it's much easier to just
set a kernel parameter.

-- Jamie