On 02/15/2011 11:31 AM, torbenh wrote: > hmm... how do you detect a spawning RT thread ? I changed a lot of rt detection yesterday. Now a process that ever got rt in one thread is moved to a rt group with lots of rt power, and will never leave it again. This should prevent that a process sets and releases rt more often and would leave the group and could rt starve. I know thats a problem, one thing is that i refresh in a interval all processes and threads. The next thing is to add a whitelist for rt programs. So, the worst thing that could happen is that a process spawning a rt thread will live one interval with very little rt time. > you are still ignoring jack. > your X plugin seems to move the currently active pid into a separate > cgroup. what happens to the RT threads of that process ? > if they move into a cgroup with not much rt_runtime the whole jack graph > will get disturbed. > > it seems like we need to rely on luck here, that only the process leader > is moved, and not too quick, so that child threads dont end up in that > cgroup. Yes. I saw this problem, too. I now observe all kernel processes, not just the process leader. Many programs seem to set the rt prio only on threads and this caused problems. The rules are traveled top to bottom, the first rule that matches will be used. If it contains children, those are tested. So, the new rt group is very top, so it will never get moved into another group as long as the check function matches. > i basically share your feelings that libcgroup seems to be too bloaty. > but such concerns should get raised on libcgroup-dev. I usually tend to just fix problems and attach a bugfix to the ticket, but when obvious bugs don't get fixed, my passions for a project falls quite deep :-) kind regards Daniel _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
