[lkml]   [2005]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RT patch acceptance
    On Wed, May 25, 2005 at 01:21:24AM +1000, Nick Piggin wrote:
    > Maybe there are damn few because it is hard to get right within
    > the framework of a general posix environment. Or maybe its
    > because it has a comparatively small userbase (compared to say
    > mid/small servers and desktops). Which are neither completely
    > invalid reasons against its inclusion in Linux.

    Rest assured RTOS companies are going to flip when this gets
    to the mainstream. You might not be aware of this, but this is
    probably end up being the single most important patch in the
    software industry when it hits the mainstream. There's been
    an over emphasis on desktop/server and really persistent lack
    of understanding of the embedded market and growth within it.

    One of the main reasons why Linux isn't used for more embedded
    systems is the lack of hard RT abilities. With this patch, it
    has a chance to hit a large section of future consumer devices,
    audio/video, with the performance of frame accurate SGI IRIX
    boxes. SGI XFS supports some of these features but is under
    utilized at this moment partially as a side effect of poor
    Linux latency performance. As app folks start to use this more
    the more various subcomponents will get fixed.

    There's a lot of bad X11 and other app code out there in

    There's active work in for getting the userspace mutex stuff
    down, robust mutexes, so that the RT app folks can have a lot
    more solid development environment for traditional RT applications.
    However, traditional applications aren't where the excitement

    The non-traditional stuff, SGI and friends, is really where I
    have my interests because I'm sick of jumping/droppy media
    applications. Current schedulers, particularly the priority
    based ones, aren't suitable for temporally partitioning run-away
    applications from other apps. Introducing the RT patch so that
    the scheduler has high resolution material to control along with
    an appropriate frame driven scheduler can fullfill this need.
    It is in a lot of ways like introducing multitasking OSes for
    the first time to people who are use to MSDOS. Multimedia apps
    tended to collide with each other in that regard.

    With this, Linux has a strong possibility be a top gaming/multimedia
    platform almost over night with retuned apps and such. Microsoft
    can't do anything about it when this happens and we're so close
    right now to pull it off. Having a fully preemptive core is
    the precondition for all of this work.

    > But I want to be clear that I haven't read or thought about the
    > code in question too much, and I don't have any opinions on it
    > yet. So please nobody involve me in a flamewar about it :)

    The code is pretty mild for the most part and fixes a lot of
    preexisting hacks (spin-waiting in drivers) in the kernel. If
    anything it's triggered some preexisting bugs and stressed the
    system in ways that would still be difficult to trigger in SMP

    It's not terribly intrusive, nor does it alter the basic
    concurrency structures of the kernel. If you'd like me to, I can
    explain this patch to you in private. :) I was working on a
    parallel project to Ingo's patches and got pretty far, but have
    abandoned it for Ingo's stuff since he's knows the kernel much
    better than I do, fixes things faster, etc...


    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-05-25 01:21    [W:0.025 / U:0.804 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site