[lkml]   [2005]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
    Peter Williams <> writes:
    > If the average usage rate is estimated over longer periods it will be
    > lower allowing lower limits to be used. Also if the task's own usage
    > rate estimates are used to test the limits then the limit can be lower.
    > If the default limits can be made sufficiently small then the
    > temptation to use this feature by "ordinary" applications will
    > disappear.
    > I'm not an expert but I imagine that the CPU usage rates of most RT
    > tasks taken over reasonably long time intervals is quite low and
    > therefore the default limits could also be quite low without adversely
    > effecting the programs that this mechanism is meant to help.

    True for some, but definitely not for all.

    When a system was purchased specifically to do some realtime job, it
    often makes sense to dedicate large chunks of the main processor to
    realtime number crunching. Mass-produced general-purpose processors
    have excellent price/performance ratios. There's no good reason not
    to take advantage of that.

    People commonly run heavy Fast Fourier Transform or reverb
    calculations in realtime threads. They may use up as much of the CPU
    as the user/owner is willing to allocate. With soft realtime, its
    hard to push this reliably beyond about 70-80%. But, those numbers
    are definitely practical.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.020 / U:52.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site