21 Jun
2009
21 Jun
'09
9:41 p.m.
On Mon, 2009-06-22 at 00:15 +0200, Lennart Poettering wrote:
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.
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).
-- Fernando
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.