Re: RT patch acceptance

[Bill Huey (hui) <bhuey@lnxw.com>]

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.

bill