[LAU] audio configuration for ulatencyd

[Daniel Poelzleithner]

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.


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

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


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

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20110214/cd1f6c49/attachment.pgp>