Lennart Poettering wrote:
On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
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.
this demonstrates nicely that there is no solution to the problem (or
that i don't understand what problem you are trying to solve).
any user that gets rt privileges can DoS the machine. actually, one
person's creative act is another person's DoS :)
if you try to guard against forkbombs, you are obviously under the
illusionary impression that you can guide against malicious users. you
can't. with your new bit of policy, i just write a bomb that eats up
100% for 9.9s, then yields for as long as your daemon needs to be
pacified, then hog the machine again.
so what is this about? rt users want absolute control over their
machine. anybody who can tolerate some arbitrary bits of policy thrown
at them during work is by definition not an rt user.
rt users must be trustable with root access, at least in terms of cpu
governance, which is what rtlimits achivev just fine.