On Mon, Feb 14, 2011 at 05:47:40PM +0100, Robin Gareus wrote: > 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. 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. > > 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@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user -- torben Hohn _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
