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