14 Feb
2011
14 Feb
'11
7:40 p.m.
On Mon, Feb 14, 2011 at 05:47:40PM +0100, Robin Gareus wrote:
--
torben Hohn
On 02/14/2011 04:33 PM, Daniel Poelzleithner wrote:
each group has a cpu.shares value and a rt_runtime_us (along with other
values).
cgroup_a cpu.shares 10:
task 1
task 2
cgroup_b cpu.shares 5:
task 3
task 4
imaging all 4 tasks want 100% cpu time, then in this setting task 1 & 2
get 66% of the cpu time and task 3 & 4 get 33%.
if you put all in one group: very task gets the same cpu time.
shares that are not used will always be given to other slots, so there
is no disadvantage in giving a group a higher share.
finding good groups of processes is of course not a easy task to get
right. the current grouping works very well for desktops.
i ment of course the complete graph. If you get like 4 cores, you move
all processes to 1 core and use the 3 remaining cores to do audio only.
aww right /me slaps head.
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.
On 02/14/2011 03:15 PM, Robin Gareus wrote:
JACK sets up these threads, but they reside in the context of the client
app's process ID - which call jack_client_new().
All processes/threads that inherit the RT
privileges from JACK.
Are these processes parent of jack or do they just connect to it ? If these are only connected, how can i get a list
of all pids in the graph ?
there was a recent discussion on jack-devel:
http://comments.gmane.org/gmane.comp.audio.jackit/23110
also check the jack-devel archive starting December 15 2010:
http://comments.gmane.org/gmane.comp.audio.jackit/22928
and http://trac.jackaudio.org/wiki/Cgroups might be helpful.
do you have me same simple command i just can run
that causes non
trivial load on jackd and it's childs to test ?
The easiest is to start jackd and jamin. The latter sucks ~15%-50% CPU
alone (depending on your CPU freq). Tou can also start a few instances
of jamin.
http://rg42.org/gitweb/?p=jackfreqd.git;a=blob_plain;f=tools/busyjack.c
is a small tool that allows to generate JACK DSP and CPU load. Start a
few of them (depending on how many cores you have).
of course. PA is for desktop usage, not pro audio
:-)
hehe, my desktop - for example - also runs on JACK (+ alsa-plug for
flash etc).
• would it be better to just put everything into one
cgroup instead of
many smaller groups ? maybe just make exceptions for ui apps and the
rest into one group ?
In order to come to a conclusion of "what is better". Could you please
outline advantages/disadvantages of each approach? There are
other neat things that could be done:
• move all away from one processor and move jackd for example on it,
giving him lowest latency possible. ok, not perfect as the kernel may
still use this cpu. But interrupts can also be masked on the core.
That would void the parallel execution of jack2 and tschack graphs,
wouldn't it? The main JACK-process is not CPU heavy: it's the JACK
client's threads that cause the CPU load.
Thanks for the explanation.
Let me comment on those later or tomorrow, I've got a train to catch.
maybe s.o. else (jack-devs: wink wink nudge nudge) can jump in..
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"
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.
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.
what about a configuration like this:
- rt_audio: cpu.shares 3000 rt: 99%
- desktop ui: cpu.shares 500 rt: 0
- audio ui: cpu.shares 2000 rt: 0
- the rest: cpu.shares 100 rt: 0
?
looks like a good starting point to me.
kind regards
daniel
Cheers!
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user