14 Feb
2011
14 Feb
'11
5:47 p.m.
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.
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..
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. 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