linuxaudio.org

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.

quoted text
> 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.

quoted text
> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user