On 02/15/2011 05:16 PM, torbenh wrote: > well... your interval seems to be 500ms. i guess you mean the delay queue here. thats a delay before a process is even looked at, because you have so many short living processes, that running the rules on them is just useless. It makes of course some rules harder to implement, like cating the parent of a process as it may already be parent of root when the delay hits... If I implement whitelists, I will hook it into this loop so it will circumvent it. > thats pretty long from our POV. if a jack client is starved, it will > generally be kicked from the graph. > and in 500ms we are doing more than 100 processing cycles. > > the problem is that you can not overcommit the RT timeslices. > so in order to have a bit of runtime in all the groups, this needs to be > subtracted from the main RT group. > > and you need runtime != 0 or the thread cant obtain SCHED_FIFO in the > first place. One problem is, that the rt_runtime_us is not hierarchical as I understood the problem. So when i have group a with limit 10 and two childs with each limit 10, they both could result in 20 spent and are not capped by the 10 limit of the parent, right ? I'm thinking about some workarounds. - Giving the groups a larger rt slot that is substracted from the rt group. - Writing a simple kernel module that would move rt threads to a given group. I saw you on the kernel mailinglist before and you seem to have more insights then I have. Is this possible ? - Writing a autowhitelist plugin that remembers tasks that got rt prio before and moves them accordingly. > of course we only set it on threads. > it doesnt make any sense to set it on the ui threads. Sure. Sorry to sound like a noob, i never used rt actively before :-) > problem is that we can not bother distro maintainers to provide N > formats of whitelists. I'm 100% pro unified whitelist :-) As long as the format does not contain unnecessary specifics for certain implementations and is not that heavy to parse :-) shall we start a wiki page, maybe on freedesktop to drop ideas and requirements ? > so we probably need to modify jack to do some ipc to somewhere before it acquires > RT privileges, but this doesnt help the non jack clients. yes, that would be great. I suggested some generic interface on the freedesktop mailinglist as i think that a generic interface between userspace and a system optimizer is required. Unfortunately there was zero response... There are a lot of potential there for all system types. kind regards Daniel _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
