On 02/17/2011 11:04 PM, Fons Adriaensen wrote:
Thank you. This, as described in Documentation/scheduler/sched-rt-group.txt is
exactly what I was looking for. A cgroup may indeed be required for all clients,
with another cgroup for the sound server.
> Still this provides protection against any RT-process that goes
Reading sched-rt-group.txt it seems to me like if the limit is exceeded, RT
processes are preempted until the end of the period, which sounds very good. I
assume that's what you mean by "blocked".
If the sound server is in its own cgroup then system audio shouldn't be affected
by bogus user-space clients. But, in the context of Android, I'm a bit worried
about the fact that one bogus realtime app could affect all other running
realtime apps. On Android, there are background processes, and users could be
misled if they see that a foreground app starts to malfunction, when it's
actually caused by a background process.
I think that ideally, the system should detect the offending app, freeze it, and
pop up a dialog to inform the user. That's already the way it works when an
application is not responding or crashes.
I am not sure how that would be feasible. Maybe with das_watchdog as mentioned
by Paul or something custom/similar?
Alternatively, the system could refuse to run more than one realtime client at
the same time. But how to do that? Maybe by having the sound server dynamically
assign the client to a cgroup only if possible, or refuse and report an error to
the client otherwise?
Linux-audio-dev mailing list