[LAU] audio configuration for ulatencyd

[torbenh]

On Mon, Feb 14, 2011 at 08:10:26PM +0100, Daniel Poelzleithner wrote:
> On 02/14/2011 07:40 PM, torbenh wrote:
> 
> > and whats the point of using only 3 cores for RT threads ?
> > other that they arent useable for normal stuff anymore ?
> > these threads are SCHED_FIFO. if they get runnable, they will get a
> > core. if the graph topology only uses 2 cores. that third core could do
> > somthing useful and execute SCHED_OTHER stuff.
> 
> It was just an idea to help reducing latency by preventing rt threads to
> move to other processors. currently the processes could still be
> interrupted by in irq i think, masking the irq handler off from those
> would change that.

hmm... indeed. i tend to forget normal kernels with non preemptible
irqs.

> 
> 
> > i only see problems on the horizon.
> > the cgroups patch is not in jack1. if ulatencyd starts messing with
> > audio threads, this would probably conflict with libcgroup.
> > 
> > without that patch to jack, we need a whitelist.
> > which still prevents things from "just-work"
> 
> i got it running with ulatencyd, but i will need to change some things
> in the core to make it better and safer first.

hmm... how do you detect a spawning RT thread ?

> 
> > the root cause is probably that rt_runtime_us is in the cpu subsystem.
> > autogroups seem to be a lot more sensible for the jack usecase.
> > 
> > maybe a cgrulesengd rule for the video player... that seems like enough
> > for me.
> 
> not for me :-)
> 
> i want perfect latency on my desktop gui, more cpu to the active program
> I'm using, protection against amok processes, swap of death and io
> bottleneck situations. whatever i do, how crazy it may be like a make -j
> 40 on the linux kernel, the desktop needs to feel fast: and that it does :-)

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.


> 
> 
> > i am a bit worried that we seem to have ulatencyd and cgrulesengd
> > competing here. this is too much based on blacklist/whitelist stuff, and
> > if there isnt a single format, this is going to be a big mess.
> 
> cgrulesengd and ulatencyd clash and won't work together. The config
> format of libcgroup doesn't make sense for ulatencyd as it works
> completely different.
> 
> In fact, i even tried libcgroup for the cgroup low level stuff and
> dropped it as it was just to buggy, bloaty and hard to use.

i basically share your feelings that libcgroup seems to be too bloaty.
but such concerns should get raised on libcgroup-dev.

> 
> What i will do soon is to write a plugin that parses easy to use config
> files, so processes can be flagged easier.
> 
> kind regards
>  daniel
> 
> 
> 



-- 
torben Hohn