Re: [LAU] audio configuration for ulatencyd

On Tue, Feb 15, 2011 at 04:17:05PM +0100, Daniel Poelzleithner wrote:
> 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.

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.

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

of course we only set it on threads.
it doesnt make any sense to set it on the ui threads.

>
> 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 :-)

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.

>
>
> kind regards
> Daniel

-- 
torben Hohn
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user