Maybe your softwares support load-sharing over multiple processors (a
good thing, no?) and therefore all the work is being neatly divided
between the processors. Any reason that should be bad?
Dan
2009/5/1, Atte André Jensen <atte.jensen@email-addr-hidden>:
> Arnold Krille wrote:
>
> > I don't understand your question?
>
>
> Ok.
>
>
> > chuck and ams are independant applications, there is no reason why they
> > shouldn't run in parallel on different cores.
>
>
> We agree on that.
>
>
> > Both use threads to split their work, again there is no reason they have all
> > their threads running on the same core. In fact one of the reasons to use
> > threads is to make use of multiple cores within one app.
>
>
> But doubling the load (for instance by adding more voices to ams) makes
> *both* threads rise by (about) 100%. Wouldn't you expect for instance
> gui threads to stay the same. Other cpu heavy processes seem to use only
> one core, for instance building stuff from source. Also...
>
>
> > With standard jack it *should* be that all jack-related threads run on one
> > core, in your case leaving the second core for gui- and disk-threads. jackdmp
> > makes use of multiple cores as far as I know.
>
>
> ...chuck is non gui and the code I'm running in chuck (my own) doesn't
> use disk i/o. Starting ams with -n (nogui) it still takes up two
> threads. It looks like this in htop:
>
> http://atte.dk/download/ams_nogui.png
>
> So one thread with prio 20 and one with -76 chewing away at the same 27%.
>
> It might be totally normal and totally unavoidable, but I'm just curious
> and doubtful :-)
>
>
> --
> Atte
>
> http://atte.dk http://modlys.dk
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
-- http://www.mcld.co.uk _______________________________________________ Linux-audio-user mailing list Linux-audio-user@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-userReceived on Sat May 2 00:15:02 2009
This archive was generated by hypermail 2.1.8 : Sat May 02 2009 - 00:15:02 EEST