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

    * Matt Mackall <mpm@selenic.com> wrote:

    > > > What happened to the RT rlimit code from Chris?
    > >
    > > I still have it, but I had the impression Ingo didn't like it as a long
    > > term solution/hack (albeit small) to the scheduler. Whereas the rt-lsm
    > > patch is wholly self-contained.
    >
    > I think it's important to recognize that we're trying to address an
    > issue that has a much wider potential audience than pro audio users,
    > and not very far off - what is high end audio performance today will
    > be expected desktop performance next year.

    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].

    I agree (and hope) that tomorrow's "stock" desktop will be based on
    today's pro audio architectures, but tomorrows CPUs will be much faster
    and tomorrows desktop apps dont want to spend 30%+ CPU time on creating
    audio.

    the pro applications will always want to have a 100% guarantee (it
    really sucks to generate a nasty audio click during a live performance)
    and want to utilize as much CPU time for audio as needed. They are also
    clearly the most complex creators of audio so they go far above the
    normal (and reasonable) CPU-use/latency expectations and tradeoffs of
    the stock scheduler.

    > So I think it's critical that we find solution that's appropriate for
    > _every single box_, because realistically vendors are going to ship
    > with this "wholly self-contained" feature turned on by default next
    > year, at which point the "containment" will be nil and whatever warts
    > it has will be with us forever.

    an "RT priorities rlimit" is still not adequate as a desktop solution,
    because it still allows the box to be locked up. Also, if it turns out
    to be a mistake then it's already codified into the ABI, while RT-LSM is
    much less 'persistent' and could be replaced much easier. RT-LSM is also
    more flexible and more practical. (an rlimit needs changes across a
    number of userspace components, delaying its adoptation.)

    > 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.

    perhaps, if the need arises, we can add the RT-throttling sysctl (which
    still wont give RT priorities to unprivileged users and would serve as a
    way to throttle privileged RT tasks), which could thus make the RT-LSM
    solution pretty safe. Right now Jack has its own watchdog thread which
    should solve most of the lockup situations. Lets not overdesign the
    solution, especially when we dont yet know how the problem really looks
    like.

    or an even simpler solution for the lockup problem would be a
    kernel-based RT watchdog. In fact 2.6.11-rc3-mm2 already includes such a
    watchdog (written by yours truly):

    http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/broken-out/detect-soft-lockups.patch

    right now softlockup-detect runs at SCHED_FIFO prio 99 and only prints a
    warning - but it could easily run at SCHED_FIFO prio 1 [to detect
    lockups generated by all RT tasks] and it could actively try to renice
    (or kill) tasks that run for too long. So very likely there will be an
    easy upstream mechanism for any problem that could arise out of RT-LSM.

    Ingo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:4.622 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site