IRQ balancing

[Sean Neakums <sneakums@zork.net>]

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.