Start irqbalance by default

[Matt Zimmerman]

On Mon, Jan 11, 2010 at 11:14:20AM +0100, Martin Pitt wrote:
> Hello all,
> 
> 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. How can it be
> more efficient to schedule interrupts in an userspace daemon than in
> the kernel itself (where it is already done presumably)?

As I understand it, irqbalance sets policy in the kernel based on observed
behavior of the system over time.  This seems well suited to a userspace
program.

I'm not sure why it needs to run all the time, though, rather than (say) as
a cron job.  It has a --oneshot option which might be suitable for this.

> 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?)

It's looking at statistical behavior, e.g. how many IRQs particular devices
have generated over a period of minutes or hours, and uses that information
to provide the kernel with scheduling hints.  I think running it a few times
per hour at most would be sufficient.

> >  - How much is the CPU overhead resulting from running the daemon in the
> >    event that there's only one core?
> >  - Are there downsides to running irqbalance on SMP systems - e.g., does
> >    using both CPUs for IRQs mean waking up processors that otherwise would
> >    be allowed to sleep, resulting in more power usage on systems where
> >    performance is not the primary concern?
> 
> That's my primary concern, too. Do we have some measurements about
> this?

I haven't looked into it, but intuitively I would think there are tradeoffs
to be made here, e.g. optimize for power consumption vs. throughput vs.
latency.  irqbalance looks fairly simple today, but could presumably be
extended to be more tunable.

> Chuck, did you actually intend to install this on all desktop systems
> as well, or just servers (where performance might matter more).

It seems appropriate for both.

-- 
 - mdz