On 02/17/2011 11:04 PM, Fons Adriaensen wrote: > On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus wrote: > >> /proc/sys/kernel/sched_rt_runtime_us >> /proc/sys/kernel/sched_rt_period_us >> >>> I've been told than on OSX, when a process runs in realtime, it is only >>> allowed >>> to use a certain ratio of CPU time. And if it goes over this limit, it >>> loses its >>> priority. Is there something comparable on Linux? Maybe with the files in >>> /proc/sys that you mention? >> not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime >> scheduling time. To limit it per process you'll need cgroups.
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 > out of control. If the limit is exceeded, all RT procs will be > blocked for the next sched_rt_period_us (default seems to be 1s), > which should give you the opportunity to kill the offending process. 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? -- Olivier _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
