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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
