lkml.org 
[lkml]   [2009]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: report a bug about sched_rt
    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



    \
     
     \ /
      Last update: 2009-07-25 01:33    [W:2.312 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site