15 Feb
2011
15 Feb
'11
11:32 a.m.
On Mon, Feb 14, 2011 at 08:10:26PM +0100, Daniel Poelzleithner wrote:
hmm... how do you detect a spawning RT thread ?
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 basically share your feelings that libcgroup seems to be too bloaty.
but such concerns should get raised on libcgroup-dev.
On 02/14/2011 07:40 PM, torbenh wrote:
hmm... indeed. i tend to forget normal kernels with non preemptible
irqs.
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
--
torben Hohn