Re: SMP interrupt wierdness in Linux 2.6.8.1 - Interrupt Load Balancing not working

Johan Kullstam <[email protected]> 07 Nov 2004 15:15:33 -0500
Newsgroups org.kernel.vger.linux-smp
Message-ID <[email protected]>
NOULARD Eric <[email protected]> writes:

> I just compiled and booted 2.6.9
> the result is almost identical interrupt seems to 
> goes only to CPU0 (excepted some of them ??)
> 
> My kernel config says:
> CONFIG_IRQBALANCE=y
> 
> 
> > cat /proc/interrupts
>            CPU0       CPU1
>   0:    6350285         14    IO-APIC-edge  timer
>   1:       8647          0    IO-APIC-edge  i8042
>   2:          0          0          XT-PIC  cascade
>   5:     166414          0    IO-APIC-edge  SoundBlaster
>   7:          1          1    IO-APIC-edge  parport0
>   8:          0          1    IO-APIC-edge  rtc
>  12:     176710          0    IO-APIC-edge  i8042
>  16:     375735          0   IO-APIC-level  r128@PCI:1:0:0
>  17:         29          1   IO-APIC-level  aic7xxx
>  18:     110899          1   IO-APIC-level  sym53c8xx, sym53c8xx
>  19:      26444          0   IO-APIC-level  uhci_hcd, eth0
> NMI:          0          0
> LOC:    6350405    6350423
> ERR:          0
> MIS:          0
> 
> 
> all /proc/irq/<irqno>/smp_affinity mask are set to 'ffffffff'?
> 
> I do not have any idea why this happen?

This is what my SMP computer looks like too.  I think it is supposed
to be this way.

Sometimes I see one IRQ jump to the second CPU.  For example, once in
a while CPU1 will start to handle all the IRQ0 timer events.


Why is it like this?  Reasoning goes something like:

When a CPU runs one task, its cache fills with running task data and
code.

When switching tasks, you need to load up new cache stuff by reading
slower memory (and perhaps disk).

A scheduler will give enough time to a task to make the switch cost
low.  It needs to switch often enough to preserve the illusion (to you
the user) of doing multiple things at the same time.  But in general,
it is better to stick with the same task as long as you can.

Interrupts are serviced as they arrive - the hardware forces the CPU
to pay attention.  This can trash the cache.  Total performance goes
down because the CPU is idle while waiting on slow RAM to fill into
the cache rather than doing anything useful.

Hence, let one CPU get creamed by the interrupt load and let the other
get on with its business.

> SideNote: My preceding irq sharing trouble disappeared when I switch
>           from MPS 1.1 to MPS 1.4 support in BIOS.

With the old PPro, I had better luck with MPS 1.1 than 1.4.  PPro IO-APIC
only has the basic 16 IRQs.

Since then, using dual AMDs, I have had better luck with MPS 1.4.  The
newer APICs give more IRQs and hence less shared interrupts.


I hope this helps.

-- 
Johan KULLSTAM