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.
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.
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 :-)
Linux-audio-user mailing list