21 Jun
2009
21 Jun
'09
10:20 p.m.
On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote:
On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:
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.
On Sun, 21.06.09 11:09, Paul Davis
(paul(a)linuxaudiosystems.com) wrote:
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. 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. 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