On 02/14/2011 04:33 PM, Daniel Poelzleithner wrote: > On 02/14/2011 03:15 PM, Robin Gareus wrote: > >> All processes/threads that inherit the RT privileges from JACK. > > Are these processes parent of jack or do they just connect to it ? JACK sets up these threads, but they reside in the context of the client app's process ID - which call jack_client_new(). > 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? > > 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. > >>> 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. > > 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.. > 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
