Description of Problem:
Interrupts are only routed to the lowest numbered processor instead of being
distributed to all processors. I can force an interrupt to be routed to an
individual processor (using /proc/irq & smp_affinity) if only that _single_
processor is selected. If more than one processor is selected, the interrupt
is routed to the lowest numbered processor.
This is in a Intel E7500-based (Tyan S2720) system with two 2.2GHz P4 Xeon
CPUs. Turning on/off HyperThreading doesn't matter.
I couldn't find any information of this in Intel's documention for the E7500
Version-Release number of selected component (if applicable):
RedHat 7.3 errata (2.4.18-4smp)
Steps to Reproduce:
1. see attachment
I expected interrupts to be routed to different CPUs when smp_affinity is
Created attachment 58144 [details]
steps to reproduce
Created attachment 58145 [details]
Created attachment 58146 [details]
Created attachment 58147 [details]
Thanks to intel for changing the apic rules... Note that w2k has the same issues.
We have a patch to fix this; question is if it's important enough (since it's a
patch that's not risk free)
Can you attach the patch to this bug? What are the risks? Any pointers to
Intel PDF's/chipset documentation that describes the changed behavior?
In your professional opinion, what is the performance impact of all interrupts
being handed by a single CPU?
Under normal workloads there won't be any measureable difference (in fact, it
can be slightly better due to better cache use). However it is measureable in a
specweb benchmark with 4 GigE cards.
I've seen Ingo Molnar's apic-route patch on SourceForge for a 2.4.18 Linus
kernel. Is this similar to the RedHat patch? Does RedHat have a patch for
2.4.18-4 (7.3 errata kernel)? If so, can you attach it? Thanks
the irqbalance patch is in the 2.5 kernel series, but it obviously has not seen
the kind of extensive testing like the stable 2.4 kernel series. This is why
such a patch, which changes so fundamental parts of the irq code, should be
treated with extreme care.
having said that, i got pretty good feedback wrt. irqbalance, it improves
performance on a number of (non-P4) server workloads, besides solving the P4 irq
routing bug. (due to the added and automatic cache-affinity properties of the
looks like the 2.4.18-17.7.x release has this patch. just confirmed on a bigmem
machine. ok to close.