15 Feb
2011
15 Feb
'11
4:17 p.m.
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