1 May
2009
1 May
'09
2:39 p.m.
Hi
I'm on a dualcore CPU (intel) here.
Running chuck and ams (and others, these are just examples) I see both
processors being used with about the same load. Shouldn't it be on just
one core, with multiple instances sharing the power of the two cores
together?
1) Is it my system that is set up wrong?
2) If somethings wrong with the programs, what could it be (I like to
hack...)
--
Atte
http://atte.dk http://modlys.dk
1 May
1 May
3:15 p.m.
On Friday 01 May 2009 18:39:04 Atte André Jensen wrote:
Running chuck and ams (and others, these are just
examples) I see both
processors being used with about the same load. Shouldn't it be on just
one core, with multiple instances sharing the power of the two cores
together?
I don't understand your question?
chuck and ams are independant applications, there is no reason why they
shouldn't run in parallel on different cores.
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.
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.
Have fun,
Arnold
3:38 p.m.
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
4:52 p.m.
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(a)gmail.com>om>:
Arnold Krille wrote:
--
http://www.mcld.co.uk
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
9:34 p.m.
Dan S wrote:
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?
No, what would be great. Unfortunately I'm pretty that's not what's
happening. With the same patch I can run 35 (but not 40) voices in ams
on dual core and 45 (but not 50) with one core disabled:
http://atte.dk/download/ams_dual_poly35.png
http://atte.dk/download/ams_single_poly35.png
http://atte.dk/download/ams_single_poly40.png
So performance is (or seems to me, not knowing much about the inner
working of neither a dualcore cpu or linux multicore implementation to
be) slightly better with one core.
--
Atte
http://atte.dk http://modlys.dk
10:18 p.m.
On Sat, May 02, 2009 at 01:34:03AM +0200, Atte André Jensen wrote:
Dan S wrote:
Just guessing, but it could be that with two cores
the audio thread (which would be responsible for most
of the load) gets scheduled randomly on one of the two
cores, which may have a penalty. This is possible as this
thread will sleep at the end of each period, waiting for
the next, and would also explain the nearly equal load
levels which you see.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
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?
No, what would be great. Unfortunately I'm pretty that's not what's
happening. With the same patch I can run 35 (but not 40) voices in ams
on dual core and 45 (but not 50) with one core disabled:
7:16 p.m.
Hi,
On Friday 01 May 2009 19:38:53 Atte André Jensen wrote:
Arnold Krille wrote:
I looked at your screenshot. As I am not familiar with your [ah]top, only with
plain old top: 1) It reports different TIME+ values for the different threads.
So they are basically not doing the same which is a good thing but maybe 2)
your top has a problem with CPU% with multiple threads and reports the apps
total for each thread...
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...
Here building stuff from source uses 10 of 8 cores. "-j X" is your friend and
rule of thumb says that X should be number_of_cores+1 to keep your room warm.
Have fun,
Arnold
3 May
3 May
8:29 a.m.
On Fri, May 01, 2009 at 11:15:44PM +0200, Arnold Krille wrote:
Hi,
On Friday 01 May 2009 19:38:53 Atte Andr? Jensen wrote:
It has been a while since I set up my dual-core system, but IIRC there was some kind of
load-distributing daemon which I had to turn off in order to get audio to work properly.
-ken
Arnold Krille wrote:
I looked at your screenshot. As I am not familiar with your [ah]top, only with
plain old top: 1) It reports different TIME+ values for the different threads.
So they are basically not doing the same which is a good thing but maybe 2)
your top has a problem with CPU% with multiple threads and reports the apps
total for each thread...
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...
Here building stuff from source uses 10 of 8 cores. "-j X" is your friend and
rule of thumb says that X should be number_of_cores+1 to keep your room warm.
12:31 p.m.
Ken Restivo wrote:
It has been a while since I set up my dual-core
system, but IIRC
there was some kind of load-distributing daemon which I had to turn
off in order to get audio to work properly.
I'd be most interested in anything getting me closer to that. Could you
recall a bit more so I have something to throw at google? Or maybe
others could supply more info regarding this?
--
Atte
http://atte.dk http://modlys.dk
6:08 p.m.
On Sun, May 03, 2009 at 04:30:54PM +0200, Atte Andr? Jensen wrote:
Ken Restivo wrote:
IIRC, it was called "irqbalance". I had to disable it.
Also remember to turn off cpufreq, by either unloading the cpufreq modules, or setting
them manually, i.e. "sudo cpufreq-set -g userspace; sudo cpufreq-set -f xxxxx"
(set it to the max clock of your CPUs).
-ken
It has been a while since I set up my dual-core
system, but IIRC
there was some kind of load-distributing daemon which I had to turn
off in order to get audio to work properly.
I'd be most interested in anything getting me closer to that. Could you
recall a bit more so I have something to throw at google? Or maybe
others could supply more info regarding this?
9:45 p.m.
Ken Restivo wrote:
IIRC, it was called "irqbalance". I had to
disable it.
Was that a kernel config option?
Or are you perhaps talking about this:
root@vestbjerg:~# apt-get remove irqbalance
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package irqbalance is not installed, so not removed
If that's what you mean, would that be a problem since it's not installed?
Also remember to turn off cpufreq, by either unloading
the cpufreq
modules, or setting them manually, i.e. "sudo cpufreq-set -g
userspace; sudo cpufreq-set -f xxxxx" (set it to the max clock of
your CPUs).
I believe that shouldn't be a problem if I have set
System->Preferences->Power Management->On AC Power->Computer speed
policy to "Always maximum speed", right? At least (when on AC power) my
cpufreq applet always shows "2.00 GHz", which is the maximum speed of my
cpu...
--
Atte
http://atte.dk http://modlys.dk
5 May
5 May
1:07 a.m.
On Mon, May 04, 2009 at 01:44:55AM +0200, Atte Andr? Jensen wrote:
I don't know what GUI you're using, and I don't use one myself, so I can't
answer that with any certainty. But if you run cpufreq-info, it should tell you which
governor you're using. If it's "userspace", and the CPU frequency is at
maximum, then you should be fine. "Performance" is *not* the same thing, IIRC.
The "performance" governor will still change your frequency and might cause
glitches. Then again, it might be fine for you. For example, I've seen advice to
remove the kernel modules completely in order to assure that there is no throttling going
on, but that hasn't been necessary for me.
-ken
Ken Restivo wrote:
Ya, that's the one.
IIRC, it was called "irqbalance". I had
to disable it.
Was that a kernel config option?
Or are you perhaps talking about this:
root@vestbjerg:~# apt-get remove irqbalance
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package irqbalance is not installed, so not removed
If that's what you mean, would that be a problem since it's not installed?
If you don't have it installed then obviously it's a non-problem for you :-)
Also remember to turn off cpufreq, by either
unloading the cpufreq
modules, or setting them manually, i.e. "sudo cpufreq-set -g
userspace; sudo cpufreq-set -f xxxxx" (set it to the max clock of
your CPUs).
I believe that shouldn't be a problem if I have set
System->Preferences->Power Management->On AC Power->Computer speed
policy to "Always maximum speed", right? At least (when on AC power) my
cpufreq applet always shows "2.00 GHz", which is the maximum speed of my
cpu...
3:28 a.m.
Hi,
On Tuesday 05 May 2009 05:07:09 Ken Restivo wrote:
I don't know what GUI you're using, and I
don't use one myself, so I can't
answer that with any certainty. But if you run cpufreq-info, it should tell
you which governor you're using. If it's "userspace", and the CPU
frequency
is at maximum, then you should be fine.
With the userspace-governour you shouldn't have any of the userspace daemons
running otherwise the frequency will change.
"Performance" is *not* the same
thing, IIRC. The "performance" governor will still change your frequency
and might cause glitches.
Nope, the performance-governour sets the cpu-freq to its max and stays there.
No changing apart from the first set-to-max when you load it and the frequency
wasn't at its max before.
No glitches.
The same goes for the powersave, only the frequency is set to minimum there.
Only governours to change the frequency are conservative, ondemand and
(surprise) userspace.
Have fun,
Arnold
5490
days inactive
5494
days old
linux-audio-user@lists.linuxaudio.org
12 comments
5 participants
participants (5)
-
Arnold Krille -
Atte André Jensen -
Dan S -
Fons Adriaensen -
Ken Restivo