[lkml]   [2005]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RT patch acceptance
    On Mon, May 30, 2005 at 06:54:44PM -0400, Karim Yaghmour wrote:
    > Bill Huey (hui) wrote:
    > > Think about what you need to do for app that does sound (hard RT),
    > > 3d drawing (mostly soft RT for this example), reading disk IO that's
    > > buffered.
    > >
    > > By the time you get the sound playback and IO buffering going, you're
    > > going to get a pretty complicated commuication layer already going
    > > from those points. Now think, what if you intend to do a FFT over that
    > > data and display it ?
    > >
    > > It's starting to get unmanagably complicated at that point.
    > But that's a general argument for having hard-rt in the standard
    > kernel. Which one of these steps cannot, from your point of view,
    > be implemented in a nanokernel archiecture? ... keeping in mind

    No, I'm not that saying that it's impossible. It's just that's going
    to be hell to write and maintain since you have deal with jitter across
    various domains that influence each other. It's not unlike the "avoid
    priority inversion by never letting threads of different priority lock
    against each other" argument. It needs to be seperated. But this is an
    issue for a single image system as well.

    When I think about it in terms of dual kernel primitives, I really have
    difficulty thinking about how to use the message queue stuff to integrate
    all of the systems involved in particular with shared buffers. Proper
    locking in those cases is scary to me for both methods, but at least
    the single kernel image stuff uses familiar chunks of memory that I can
    manipulate. I'm open to be proven wrong about this point if you have a
    good example sources to show me. I really am.

    > that, as Andi mentioned, the need for increased responsivness for
    > the mainstream kernel is relevant with or without PREEMT_RT and
    > that increasing responsiveness is a never-ending work-in-progress.


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