64bit kills SMP ?

Message

darkphader · Post by **darkphader** » Wed Mar 05, 2008 11:27 pm

loftwyr wrote:irqbalance is for dual core systems.
Can we see the relevant log entries?

Nothing in the logs. But I did find this forum post:http://forums.gentoo.org/viewtopic-t-66 ... lance.html

loftwyr · Post by **loftwyr** » Thu Mar 06, 2008 2:39 pm

I wouldn't worry about what one website says, the site that designs it (run by Intel) specifically mentions helping dual core processors.

darkphader · Post by **darkphader** » Thu Mar 06, 2008 3:09 pm

loftwyr wrote:the site that designs it (run by Intel) specifically mentions helping dual core processors.

More like multi-core processors on different sockets. The sparse documentation does seem to indicate that it is "socket" oriented, basically deciding which cores to place interrupts based on the "package" or socket that they are in. Different packages for "performance" mode, same package for "power" mode.

Even in debug mode no errors are provided, no syslog errors, etc. I suspect it does a check for "true physical smp", ie. multiple sockets, and the daemon exits if this isn't the case.

OK, just found this comment in the source of irqbalance.c:

/* On dual core/hyperthreading shared cache systems just do a one shot setup */

I think basically it is saying that it has little to do with a one "package"/socket system and that the daemon will not continue to run but only work in --oneshot fashion.

Chris

gimpel · Post by **gimpel** » Thu Mar 06, 2008 5:45 pm

Daemon keeps running fine on Athlon64 X2, it has a seperate cache for each core.
No idea if that means it has two sockets.

darkphader · Post by **darkphader** » Thu Mar 06, 2008 6:05 pm

gimpel wrote:it has a seperate cache for each core

That must be what makes the difference.

snIP3r · Post by **snIP3r** » Thu Mar 06, 2008 7:42 pm

darkphader wrote:
gimpel wrote:it has a seperate cache for each core
That must be what makes the difference.

i dont think so, cause also the core2duo's do have a seperate cache for each core. a hyperthreading cpu only has one cache.

darkphader · Post by **darkphader** » Thu Mar 06, 2008 7:51 pm

snIP3r wrote:i dont think so, cause also the core2duo's do have a seperate cache for each core

The info I've found claims that the cache is shared. From the Intel Core 2 Duo product brief:

The shared L2 cache is dynamically allocated to each processor core based on workload.

snIP3r · Post by **snIP3r** » Thu Mar 06, 2008 8:02 pm

darkphader wrote:
snIP3r wrote:i dont think so, cause also the core2duo's do have a seperate cache for each core
The info I've found claims that the cache is shared. From the Intel Core 2 Duo product brief:
The shared L2 cache is dynamically allocated to each processor core based on workload.

ok, thx for the info, i always thought that each core has its seperate cache - but i found some (now i know wrong) info that claims 2x X MB cache...

but i got another thing i am wondering about: some user's irq's share more balanced - with or without irqbalance installed! e.g. loser_5150 with his opteron and no irqbalance installed or streamkid with his core2duo and a installation of irqbalance also cyrre with his quadcore and irqbalance installed... so i think there might be something with the respective installation. checking my /proc/interrupts again i can see the "grouping" of the irqbalance package but not this "clean" balancing like the users i posted...

Code: Select all

cat /proc/interrupts
           CPU0       CPU1
  0:      94484  589249681   IO-APIC-edge      timer
  1:         31       6089   IO-APIC-edge      i8042
  4:        723     761603   IO-APIC-edge      serial
  8:          0          1   IO-APIC-edge      rtc
  9:          0          0   IO-APIC-fasteoi   acpi
 16:      29168   22432472   IO-APIC-fasteoi   3w-9xxx, serial
 19:          0          3   IO-APIC-fasteoi   ohci1394
 20:    1027220    4362242   IO-APIC-fasteoi   ohci_hcd:usb1
 21:          0          0   IO-APIC-fasteoi   sata_nv
 22:          0          0   IO-APIC-fasteoi   sata_nv
 23:          2         58   IO-APIC-fasteoi   sata_nv
1272:        237     193572   PCI-MSI-edge      eth1
1273:        117      96725   PCI-MSI-edge      eth0
NMI:          0          0
LOC:  589349040  589349014
ERR:          0

can someone perhaps confirm this?

greets
snIP3r

Dairinin · Post by **Dairinin** » Fri Apr 18, 2008 5:59 pm

This is _sole_ io-apic's doing. At least, how bios tells him to manage interrupts.

I saw it with my own eyes, when changing mobo from intel p965 to g33 changed the way interrupts are handled from "let-one-core-do-all-the-work" to complete per-interrupt load balance. First approach is defenetly better for dual-cores and newer quads with shared l2-cache. On another box with q6600 and p35 I saw io-apic balancing interrupts among _all_ 4 cores despite the fact q6600 has two l2 caches. On the first box irqbalance is not needed, but on the second box, network i/o performance can suffer without irqbalance. So I think it is not wise to ask for a feature because figures look "cool"

vegaman · Post by **vegaman** » Wed Apr 30, 2008 10:54 am

darkphader wrote:Decided to try irqbalance but it seems to only work in --oneshot fashion. It starts and then stops, no error messages are provided. Anyone else seeing this?

EDIT UPDATE: looks like it's because I don't have more than one socket - it's a dual-core system - irqbalance not desirable.

Sorry if I'm underestimating you, but are you running it via "/etc/init.d/irqbalance start"?
If you simply run the irqbalance executable, it will behave as you mentioned.

darkphader · Post by **darkphader** » Wed Apr 30, 2008 8:25 pm

vegaman wrote:Sorry if I'm underestimating you, but are you running it via "/etc/init.d/irqbalance start"?
If you simply run the irqbalance executable, it will behave as you mentioned.

Oddly enough it now doesn't matter how I start it, either with the init script or simply running the executable, irqbalance does daemonize. Previously it would not daemonize no matter how I ran it and would always act as if --oneshot was specified.

As I pointed out previously http://forums.gentoo.org/viewtopic-p-49 ... ml#4934159 the code seems to be designed in some cases to not daemonize. At this point I'm guessing that something is different due to a kernel upgrade that causes the new behavior.