topic Re: interrupt handling in core 2 duo - unfair balancing in Intel® Moderncode for Parallel Architectures

interrupt handling in core 2 duo - unfair balancing

synthnassizer — Sun, 20 Jan 2008 11:20:46 GMT

hello everyone, im looking for inside information on how to tweak my linux box (its a slackware linux v11, running a custom kernel 2.6.20.7 ).
i am not sure this is the right place to discuss this, yet i'm looking for possible pointers that can lead me to the right direction.

if i do
nass@stargaze:~$ cat /proc/interrupts
CPU0 CPU1
0: 1764867489 0 IO-APIC-edge timer
1: 13418 0 IO-APIC-edge i8042
4: 130276577 0 IO-APIC-edge serial
6: 3 0 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 3 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 381820 0 IO-APIC-edge i8042
16: 238 0 IO-APIC-fasteoi ohci1394, ehci_hcd:usb1, libata, uhci_hcd:usb7
17: 539010173 0 IO-APIC-fasteoi uhci_hcd:usb3, nvidia
18: 0 0 IO-APIC-fasteoi libata
19: 185580186 0 IO-APIC-fasteoi uhci_hcd:usb6, eth0
20: 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
22: 239687 0 IO-APIC-fasteoi HDA Intel
23: 6502 0 IO-APIC-fasteoi ide2, ide3
219: 32516511 0 PCI-MSI-edge libata
NMI: 0 0
LOC: 1748160692 1748160694
ERR: 0
MIS: 0

it is apparent to me that the 2nd cpu of my core 2 duo does not handle interrupts (apart from the LOC - what is this ? ).

also i am under the impression that the 2nd cpu is used less altogether since when i check the KGuard system monitor, i usually see one processor usage varying at 0-85%, and the other only at 0-4%...

any ideas how i could fix that?
thank you in advance for your help
Nass

Re: interrupt handling in core 2 duo - unfair balancing

TimP — Sun, 20 Jan 2008 14:10:44 GMT

You won't get much use of the 2nd core without a multi-threaded application or when running 2 independent applications. I'm not aware of any considerations where dual cores would improve the rate of interrupt processing.

Re: interrupt handling in core 2 duo - unfair balancing

synthnassizer — Sun, 20 Jan 2008 14:47:56 GMT

indeed without multi-threaded apps i won't go far, but i was referring to smth much more basic - ie the fact that the system wouldn't even consider using the 2nd cpu to handle some interrupts. for example when one cpu would be serving an interrupt the other could serve another interrupt... smth that wasnt the case until now..

however, i used this guide http://gentoo-wiki.com/HARDWARE_Intel_Core2_Duo to create a kernel with the options for the 32bit core 2 duo processor and now i get

nass@stargaze:~$ cat /proc/interrupts
CPU0 CPU1
0: 3265 954119 IO-APIC-edge timer
1: 38 0 IO-APIC-edge i8042
4: 64630 0 IO-APIC-edge serial
6: 3 0 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 3 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 196 0 IO-APIC-edge i8042
16: 50 0 IO-APIC-fasteoi ohci1394, ehci_hcd:usb1, ide0, uhci_hcd:usb7
17: 267656 0 IO-APIC-fasteoi uhci_hcd:usb3, nvidia
18: 0 0 IO-APIC-fasteoi libata
19: 3420585 3417181 IO-APIC-fasteoi uhci_hcd:usb6, eth0
20: 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
21: 3037 1494 IO-APIC-fasteoi ide2, ide3
22: 0 0 IO-APIC-fa steoi uhci_hcd:usb4
23: 167 0 IO-APIC-fasteoi HDA Intel
219: 43196 20717 PCI-MSI-edge libata
NMI: 0 0
LOC: 944350 944349
ERR: 0
MIS: 0

it seems far more meaningful...no? :)

Re: interrupt handling in core 2 duo - unfair balancing

jimdempseyatthecove — Sun, 20 Jan 2008 16:04:45 GMT

Multi-threaded interrupt handling would likely yield poorer performance.

Interrupt handling is a very small portion of code (or at least it should be if programmed correctly). The typical interrupt code is to acknowledge the interrupt and schedule the higher level processing code. The higher level processing code is typically multi-threaded.

Should the interrupts be distributed across processors or should the interrupts be distributed in another fashion (e.g. round robin via hardware) then there are two problems at interrupt levelto resolve. One being interrupt level priority inconsistencies, and the second, and likely more important, is the interrupt code that has to post the scheduling event must now be written using thread-safe coding practices. Thread-safe coding practices often result in SpinLocks or other "dependent on other processor" types of delays. This in turn would cause some interrupts to be blocked (in interrupt service) while all interrupts (using thread-safe code)would run slower.

Jim Dempsey

Re: interrupt handling in core 2 duo - unfair balancing

TimP — Sun, 06 Jul 2008 13:26:19 GMT

http://irqbalance.org/documentation.php