Lennart Poettering wrote:
> On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (nando@email-addr-hidden) 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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 04:15:02 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 04:15:02 EEST