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

On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (nando@email-addr-hidden) wrote:

>
> On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:
> > On Sun, 21.06.09 11:09, Paul Davis (paul@email-addr-hidden) wrote:
> > > I cannot imagine wanting to use this mechanism. You also seem to
> > > have assumed that everyone agrees that SCHED_RR is the correct
> > > policy, rather than SCHED_FIFO.
> >
> > If people can make a good case for SCHED_FIFO, then fine, we can add
> > that to rtkit.
> >
> > Personally, I believe that RR vs. FIFO is not so much a decision that the
> > programmer should make. I think this is more a decision for the admin,
> > because this influences fairness between consumers of RT.
>
> It is, ultimately, a decision for the _user_ to make. RealtimeKit should
> also take that into account.
>
> As a user doing critical audio, say, in a concert situation, I'd require
> that my computer's realtime audio tasks can use 99.9% of the cpu for
> short amounts of time. I don't care if the rest of the user processes
> are momentarily slowed down (up to a point, of course). I would very
> much care if my computer, due to a temporary overload, decides to a)
> glitch the audio and b) demote the rt process to SCHED_OTHER
> permanently. It looks like the RealtimeKit is designed to do exactly
> that by default.

By default the watchdog will only become active after 10s of complete
lockup. This should be enough. We can raise it if this turns out to be
necessary, but let's wait for a request based on real-world data
before we do something like that.

Also note that in a case like yours admin and user are usually
identically, so if you don't trust rtkit just bypass it and use
RLIMIT_RTPRIO as it was done before rtkit came into the game.

> If that is the case, how can I regain control of what I can do without
> having to resort to extreme cases of root configuration file magic, etc,
> etc (what RealtimeKit is supposed to avoid).

rtkit only comes into play as last resort when rt is cannot otherwise
be required (at least if developers follow my recommendations from the
README). If the supervised realtime sched that rtkit gives you isn't
good enough, then simply give your application unsupervised RT by
means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev