IRQ balancing

Sean Neakums
2003-12-06T14:40:37Z

William Lee Irwin III <wli@holomorphy.com> writes:

> On Sat, Dec 06, 2003 at 10:32:45AM +0800, Colin Coe wrote:
>> This indicates to me that the processing load is being evenly distributed
>> accross the two processes. Under v2.6.0-testxx however, 'cat
>> /proc/interrupts' shows this:
>> [root@host root]# cat /proc/interrupts
>> CPU0 CPU1
>> 0: 633122 30 IO-APIC-edge timer
>> 1: 207 IO-APIC-edge i8042
>> 2: XT-PIC cascade
>> 4: 48 1 IO-APIC-edge serial
>> 5: 449 1 IO-APIC-level eth1
>> 10: 135 1 IO-APIC-level aic7xxx
>> 11: 1447 1 IO-APIC-level eth0
>> 12: 61 IO-APIC-edge i8042
>> 14: IO-APIC-level CS46XX
>> 15: 14982 1 IO-APIC-level megaraid
>
> 2.6 does balancing across packages, not logical cpus, so this will
> happen and it will be largely harmless, except for what appears to
> be some kind of bug where it's stealing the timer from logical cpu 1.

I noticed something similar way back when, and what I took away from
the ensuing discussion (which may be complete poppycock) was:

"IRQ balancing" means having individual IRQs run on the same CPU as
much as possible, which (I assume) mitigates cacheline bouncing or
something along those lines. It does not mean having each IRQ
serviced equally by each CPU. The kernel's default policy is now to
have all IRQs run on CPU0, with "noirqbalance"'s effect being to
have the IRQs be serviced by CPUs in a round-robin fashion.
noirqbalance is intended to be used when one is runing a userspace
IRQ balancing policy daemon, such as the one written by Arjan Van de
Ven (http://people.redhat.com/arjanv/irqbalance/).

--
Not bad, for a human.