On 02/17/2011 09:40 PM, Olivier Guilyardi wrote:
The one thing about Android is that it has a strict
security model. Every app is
considered potentially harmful and is thus "sandboxed". Here, this for example
means that apps can lower their threads priority, but not increase it. And of
course they can only use non-realtime scheduling.
I have written a dynamic system optimizer for linux called ulatencyd. I
stumbled more by accident over rt issues my self. I use dynamic cgroups
to adjust the resources of the system to what heuristic rules think the
user expects. At least in the default desktop configuration but you can
actually optimise every system to every load.
I mainly use cgroups to group processes which get different parameters
like cpu.shares and some other values. you can use cgroups to give
strict RT slices. In fact, if you want processes to be able to get rt
you have to handle them to, when CONFIG_RT_GROUP_SCHED is set.
It is a little bit tricky and it's kind of a hack, how ulatencyd does
it, because there is no notification in into userspace when rt
scheduling is set on a thread. (There is not even a hook in the kernel
execpt the secruity module).
What ulatencyd does is to give most groups a cpu.rt_runtime_us of 1,
this is way to less to actually do rt work, but allows a process to set
rt on a thread. The current scheduler config moves processes that have
realtime threads into a rt group that have enough cpu.rt_runtime_us to
do their work, but not enough to pull down a system.
There are some drawbacks, as I don't get notifications in thread
changes, the process is only looked at in a iteration cycle. If a
process starts it's rt thread shortly after booting up, everything is
fine, as long as he doesn't instantly complain about the bandwidth
assigned. jackd for example starts up quite nicely, so does pulseaudio.
If a process starts his rt thread very late, the rescheduling could take
a iteration interval which is 10 seconds currently.
If there is a rule, that marks the process with a flag "sched.rt" it
will get moved into the rt group as soon as ulatencyd runs the process,
thats quite after delay of 1s (default). I'm thinking about adding a
special very early match list that allows to minimise this delay. It
exists because many normal processes are just very short living and it's
useless to schedule them in the first place.
If you are a process, you can put yourself into the rt group by doing in
dbus call and mark it as sched.rt and kick a schedling on the process,
this way you will instantly end up in the rt group.
Now, what you can do if you have no trust in processes at all is, to
create dynamic cgroups with carefully calculated cpu.rt_runtime_us
values for the processes. If you have trusted processes, you may give
them seperate cgroups with fixed runtimes, like for example your mixer
process. But remember: you can't overcommit rt_runetime_us and they will
not borrow their rt if they don't use it.
kind regards
Daniel