Start irqbalance by default

[Reinhard Tartler]

On Mo, Jan 11, 2010 at 11:14:20 (CET), Martin Pitt wrote:

> Steve Langasek [2010-01-08 20:14 -0800]:
>>  Description: Daemon to balance interrupts for SMP systems
>>   Daemon to balance interrupts across multiple CPUs, which can lead to
>>   better performance and IO balance on SMP systems. This package is
>>   especially useful on systems with multi-core processors, as interrupts
>>   will typically only be serviced by the first core.
>
> To be honest, this sounds a bit like black voodoo to me.

It is. Moreover, I find the package description a bit misleading.

> How can it be more efficient to schedule interrupts in an userspace
> daemon than in the kernel itself (where it is already done
> presumably)? 

It doesn't and it cannot. Interrupts need to be processed in kernel
context, although they may trigger other threads that may or may run in
userspace. This is not what irqbalance does. What it does is to
reprogram the APIC to balance the incoming irq from hardware on
different processors.

In order to judge the "performace", you first need to define if you are
looking at latency or throughput. Depending on your workload, balancing
irqs on different CPUs may or may not improve one or the other.

> Does userspace have more information about which processes are running
> and what they are going to do? If so, doesn't that involve more IPC
> and thus wakeups? If not, why isn't that alternative strategy
> implemented in the kernel itself (right now it seems that the
> scheduling would be done at two places?)

I assume (but this may be wrong) that the kernel default is to route all
irqs to the primary boot CPU. This is actually not a bad choice at all
IMO, this leaves the other CPUs unoccupied with handling hardware
request, which means that they are free to do other tasks like userspace
applications. Moreover, it guarantees that there is no concurrence
between threads that handle hardware requests (and thus avoids certain
kinds of race conditions in device drivers). This does however increase
the latency if you are on a high interrupt load.

Here at work we use 2 thin client servers (debian/lenny though) where we
have experimented with irqbalance as well. The result was that
experienced packet loss on the network card. This is certainly a bug in
the network driver that should be fixed, but you see, changing the
kernel interrupt handling model can and does have very subtle
consequences on the whole system.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4