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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
