[lkml]   [2005]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.11-rc3-mm2

    * Matt Mackall <> wrote:

    > > i disagree that desktop performance tomorrow will necessarily have to
    > > utilize SCHED_FIFO. Today's desktop audio applications perform quite
    > > good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
    > > interactivity/latency fixes such as PREEMPT_BKL].
    > Desktop performance tomorrow will want realtime audio AND video.
    > Think simultaneous record and playback of multiple high-definition
    > video streams. There's a demand for this; my company already sells it.

    Tomorrow's hardware will have enough buffering as today's hardware has
    for simpler tasks. Repeat after me: it likely _wont_ _need_ SCHED_FIFO.
    Running tomorrow's hardware on today's boxes indeed pushes the system to
    its limits, but torrows hardware will be well-balanced just as much as
    today's is - if nothing else then due to kernel drivers providing a
    buffering guarantee.

    think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
    destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
    can be useful if you _need_ a scheduling guarantee due to physical
    constraints, and it can be useful if the hardware (or the kernel) cannot
    buffer enough, but otherwise, it only causes problems.

    > I'm very suspicious about being able to rip out RT-LSM once it's
    > introduced. [...]

    yeah, i somewhat share that view. (despite all the promises from the
    audio folks - if they are just half as agressive resisting removal as
    they were pushing integration then it will never be removed ;-)

    but i'm not sure how rlimits will contain the whole problem - can
    rlimits be restricted to a single app (jackd)? The most canonical use of
    rlimits is per-user (per-group), so the rlimit could end up _widening_
    the effects of the hack ...

    > > > The rlimit stuff is not perfect, but it's a much better fit for the
    > > > UNIX model generally, which is a fairly big win. [...]
    > >
    > > a 'locked up box' is as far away from the UNIX model as it gets.
    > Rlimits are already the favored tool for dealing with the classic UNIX
    > DoS: the fork bomb. Turn off process limits, tada, locked up box.

    the big difference is that process limits are finegrained and it has a
    single value (unlimited) that allows the DoS - while the RT-rlimits have
    _one_ value that is safe, all the other values are unsafe!

    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:10    [W:0.041 / U:0.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site