On 02/23/2011 11:10 AM, Olivier Guilyardi wrote: > The dynamic cgroups solution seems good. > > On Android there basically is one priviledged and trusted audio process, > audioflinger, the sound server, which performs mixing and access the hardware. > All audio clients are untrusted. I think there is a need to both assign a > careful cpu.rt_runtime_us to each client but also to limit the number of > clients > which can run at the same time. This would allow to keep the CPU time assigned > to all clients within a certain quota, but also to prevent clients from > fighting > with each other for realtime bandwidth. > > Can you limit the maximum number of realtime processes with ulatencyd?
Yes, that should be possible, even i never used that. So, you want a first come first get policy ? There is no nice api for detecting the number of processes in a group but i will add one as i think it's a valid decision to consider. There is no per se limit of processes in a group, in fact: there is no way to limit processes numbers anyhow, unfortunately. Makes it very hard to write write a fork bomb protector ;-) But, you can of course just stop moving processes into a group. Yesterday i added a instant filter functionality that allows you with witelists to move processes extremly quickly. This is required for some daemons that request realtime and then messure the cpu time they get to test if it's enough for running smoothly. Those problematic processes must be whitelisted because the normal delay mechanism would schedule them to late, as many processes started are just short running and looking at them is just a waste of cpu time. kind regards Daniel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev