Re: CONFIG_IRQBALANCE for AMD64?

[Nivedita Singhvi <niv@us.ibm.com>]

Arjan van de Ven wrote:

> On Fri, May 28, 2004 at 10:46:18AM -0700, Martin J. Bligh wrote:
> 
>>Personally, I find the argument that it's hardware-specific control code
>>a much better reason for it to belong in the kernel. 
> 
> 
> Is it really hardware specific ??

I have limited knowledge on this, but a great deal of interest.
So, please forgive some stupid questions and wrong assumptions.

The irqbalanced is a user space daemon that attempts to
balance irqs across CPUs. It keeps track of the current
irq counts on the CPUs, and at regular intervals applies
changes to irq binding in order to implement the desired
policy. It achieves a high-level long term balance of irqs
across CPUs.

This is a fairly expensive but generally arch independent
(as long as they support cpu binding of irqs) method to
achieve long term distribution of interrupts.

I think this is best used for fairly balanced (over time)
long running workloads. For short workloads which demonstrate
intense activity in bursts, this won't be as effective.

For fine grained balancing of interrupts, I don't see how
you can avoid implementing something in hw/fw/low level
kernel.

I see networking interrupts requiring fine granularity
balancing, to avoid the potential for dropped packets and
long latencies.  That is, given a busy server that is
seeing a lot of interrupts, fair distribution of the
interrupts is required within a very small amount of time,
and we cannot require a user space daemon that parses the /proc
file system and applies a policy and then rebinds irqs
to different CPUs to run with that frequency.

I would like (with my very limited knowledge) something
that would automatically on every interrupt send it to
the optimum CPU (one that was idle, or least loaded)..
This might involve too much overhead to keep track of,
but some improvement over round robining of the interrupts
coming in should be possible..

Does this make sense?

thanks,
Nivedita