somewhere between about 2.5.53 and 2.5.62 my /proc/interrupts has gone
from an approximately even distribution of interrupts between CPU0 and
CPU1 to grossly uneven:
CPU0 CPU1
0: 13223321 2233217 IO-APIC-edge timer
1: 13442 0 IO-APIC-edge i8042
2: 0 0 XT-PIC cascade
3: 291874 0 IO-APIC-edge serial
8: 3 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-edge acpi
14: 18932 0 IO-APIC-edge ide0
15: 14 0 IO-APIC-edge ide1
16: 190607 1 IO-APIC-level eth0, nvidia
17: 3214 0 IO-APIC-level bttv0
18: 14249 1 IO-APIC-level ide2
19: 121942 0 IO-APIC-level uhci-hcd, wlan0
NMI: 0 0
LOC: 15458218 15458423
ERR: 0
MIS: 0
if i really hit the system hard then CPU1 will start accruing interrupts
but in a mostly idle state CPU1 just sits on its bum and lets CPU0
handle them all, with the exception of irq #0, for some reason.
any ideas?
thanks
James
James Harper <[email protected]> wrote:
>
> somewhere between about 2.5.53 and 2.5.62 my /proc/interrupts has gone
> from an approximately even distribution of interrupts between CPU0 and
> CPU1 to grossly uneven:
>
> CPU0 CPU1
> 0: 13223321 2233217 IO-APIC-edge timer
> 1: 13442 0 IO-APIC-edge i8042
> 2: 0 0 XT-PIC cascade
> 3: 291874 0 IO-APIC-edge serial
> 8: 3 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-edge acpi
> 14: 18932 0 IO-APIC-edge ide0
> 15: 14 0 IO-APIC-edge ide1
> 16: 190607 1 IO-APIC-level eth0, nvidia
> 17: 3214 0 IO-APIC-level bttv0
> 18: 14249 1 IO-APIC-level ide2
> 19: 121942 0 IO-APIC-level uhci-hcd, wlan0
> NMI: 0 0
> LOC: 15458218 15458423
> ERR: 0
> MIS: 0
>
> if i really hit the system hard then CPU1 will start accruing interrupts
> but in a mostly idle state CPU1 just sits on its bum and lets CPU0
> handle them all, with the exception of irq #0, for some reason.
>
That is a deliberate part of the new interrupt balancing code.
If the interrupt rate is low, it is better to keep all the interrupt
processing code and data in the cache of a single CPU.
It is only if that CPU starts to run out of steam that it is worthwhile
taking the hit of getting other CPUs to service interrupts as well.
(I think. At least, it sounds good and the benchmarks came out well).
I too had such interrupt distribution...
In my case, absolutely no interrupts was taken by CPU1, even the timer...
and I recall that timer interrupts should hit all the CPUS or strange things
can appear.
But, curiously, a
echo 3 >/proc/irq/0/smp_affinity
solved the problem for me (for IRQ 0 only of course)
I say curiously because the old smp_affinity value was 0xffffffff, so
masking the unused bits should have no effect.
Eric
> somewhere between about 2.5.53 and 2.5.62 my /proc/interrupts has gone
> from an approximately even distribution of interrupts between CPU0 and
> CPU1 to grossly uneven:
>
> CPU0 CPU1
> 0: 13223321 2233217 IO-APIC-edge timer
> 1: 13442 0 IO-APIC-edge i8042
> 2: 0 0 XT-PIC cascade
> 3: 291874 0 IO-APIC-edge serial
> 8: 3 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-edge acpi
> 14: 18932 0 IO-APIC-edge ide0
> 15: 14 0 IO-APIC-edge ide1
> 16: 190607 1 IO-APIC-level eth0, nvidia
> 17: 3214 0 IO-APIC-level bttv0
> 18: 14249 1 IO-APIC-level ide2
> 19: 121942 0 IO-APIC-level uhci-hcd, wlan0
> NMI: 0 0
> LOC: 15458218 15458423
> ERR: 0
> MIS: 0
>
> if i really hit the system hard then CPU1 will start accruing interrupts
> but in a mostly idle state CPU1 just sits on its bum and lets CPU0
> handle them all, with the exception of irq #0, for some reason.
>
> any ideas?
>
> thanks
>
> James
>
On Sun, 2003-02-23 at 10:42, James Harper wrote:
> somewhere between about 2.5.53 and 2.5.62 my /proc/interrupts has gone
> from an approximately even distribution of interrupts between CPU0 and
> CPU1 to grossly uneven:
>
> CPU0 CPU1
> 0: 13223321 2233217 IO-APIC-edge timer
> 1: 13442 0 IO-APIC-edge i8042
> 2: 0 0 XT-PIC cascade
> 3: 291874 0 IO-APIC-edge serial
> 8: 3 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-edge acpi
> 14: 18932 0 IO-APIC-edge ide0
> 15: 14 0 IO-APIC-edge ide1
> 16: 190607 1 IO-APIC-level eth0, nvidia
> 17: 3214 0 IO-APIC-level bttv0
> 18: 14249 1 IO-APIC-level ide2
> 19: 121942 0 IO-APIC-level uhci-hcd, wlan0
> NMI: 0 0
> LOC: 15458218 15458423
> ERR: 0
> MIS: 0
>
> if i really hit the system hard then CPU1 will start accruing interrupts
> but in a mostly idle state CPU1 just sits on its bum and lets CPU0
> handle them all, with the exception of irq #0, for some reason.
could you try the irqbalanced daemon for interrupt balancing:
http://people.redhat.com/arjanv/irqbalance/irqbalance-0.05.tar.gz