Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

On Tue, 2009-06-23 at 20:25 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-06-22 at 15:14 +0200, Lennart Poettering wrote:
> > On Sun, 21.06.09 20:58, Fernando Lopez-Lezcano (nando@email-addr-hidden) wrote:
> >
> > > > > The question is relevant, I think, as the kernels that I use (Planet
> > > > > CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
> > > > > think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
> > > > > support is still far in the future).
> > > >
> > > > Dunno. I disagree. The primary objective for rtkit is to be able to
> > > > run media applications as RT by default, out-of-the-box. I doubt that
> > > > this feature matters for legacy distros/kernels.
> > >
> > > I'm talking about the rt kernels specifically. In that context users
> > > don't have a real choice as to what they get to run and the meaning of
> > > legacy is different (I understand you may not care because of the target
> > > audience of PA, but then again the RealtimeKit is being proposed as a
> > > generic solution for access to rt scheduling).
> > >
> > > If the rt patch does not catch up fast enough then I may need to run a <
> > > 2.6.31 kernel (whatever is available at the time) in Fedora 12 when it
> > > is released, hardly a legacy distro :-)
>
> [MUNCH]
>
> Let's assume for a moment that when rtkit becomes part of Fedora the rt
> kernel patch has not caught up to 2.6.31, would you consider changing
> the behavior so that if the kernel does not have SCHED_RESET_ON_FORK
> (ie: it is older than 2.6.31) rtkit would still grant rt if the other
> conditions are met? Or add a boot time configuration to be able to do
> that?
>
> That would mean that _temporarily_ older rt kernels (and jack users that
> prefer or need to use them) would be able to use the same out of the box
> rt granting mechanism as the rest of Fedora.

Another point re: rt kernels...
With this in mind:

http://git.0pointer.de/?p=rtkit.git;a=patch;h=db2d157f0d8922e88689631b9de26aea30229182

I know, I know, all I keep asking about configurability...

I do have a problem with the current default priorities of Fedora's jack
(one of the reasons I override that package in Planet CCRMA). In rt
kernels the best possible performance for something like jack implies
reordering the priorities of rt processes so that highest priority is
the interrupt that services the soundcard, then comes jack, then comes
everything else (not that simple but that's the gist of it).

I use rtirq (at the bottom of http://www.rncbc.org/jack/).

A max priority of 29 does not leave much room for reordering the whole
spectrum of rt processes that are part of an rt kernel...

Is there a reason for that low priority? Can it be overriden? (the max)
-- Fernando

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Jun 24 12:15:02 2009