15 Feb
2011
15 Feb
'11
5:16 p.m.
On Tue, Feb 15, 2011 at 04:17:05PM +0100, Daniel Poelzleithner wrote:
of course we only set it on threads.
it doesnt make any sense to set it on the ui threads.
On 02/15/2011 11:31 AM, torbenh wrote:
well... your interval seems to be 500ms.
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.
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.
problem is that we can not bother distro maintainers to provide N
formats of whitelists.
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.
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
--
torben Hohn