2006-08-04 02:45:53

by Andrew Morton

[permalink] [raw]
Subject: Re: [RFC] irqbalance: Mark in-kernel irqbalance as obsolete, set to N by default

On Mon, 31 Jul 2006 10:35:26 -0700
Auke Kok <[email protected]> wrote:

> We've recently seen a number of user bug reports against e1000 that the
> in-kernel irqbalance code is detrimental to network latency. The algorithm
> keeps swapping irq's for NICs from cpu to cpu causing extremely high network
> latency (>1000ms).

What kernel versions? Some IRQ balancer fixes went in shortly after 2.6.17.

It would be better if poss to fix the balancer rather than deprecating it.


2006-08-04 14:26:34

by Kok, Auke

[permalink] [raw]
Subject: Re: [RFC] irqbalance: Mark in-kernel irqbalance as obsolete, set to N by default

Andrew Morton wrote:
> On Mon, 31 Jul 2006 10:35:26 -0700
> Auke Kok <[email protected]> wrote:
>
>> We've recently seen a number of user bug reports against e1000 that the
>> in-kernel irqbalance code is detrimental to network latency. The algorithm
>> keeps swapping irq's for NICs from cpu to cpu causing extremely high network
>> latency (>1000ms).
>
> What kernel versions? Some IRQ balancer fixes went in shortly after 2.6.17.

user reports show 2.6.17.1 having the problem, I'm trying to get more details
information, and will ask if 2.6.18rc3 or so does better for them.

Cheers,

Auke

2006-08-04 14:59:14

by Arjan van de Ven

[permalink] [raw]
Subject: Re: [RFC] irqbalance: Mark in-kernel irqbalance as obsolete, set to N by default

Andrew Morton wrote:
> On Mon, 31 Jul 2006 10:35:26 -0700
> Auke Kok <[email protected]> wrote:
>
>> We've recently seen a number of user bug reports against e1000 that the
>> in-kernel irqbalance code is detrimental to network latency. The algorithm
>> keeps swapping irq's for NICs from cpu to cpu causing extremely high network
>> latency (>1000ms).
>
> What kernel versions? Some IRQ balancer fixes went in shortly after 2.6.17.
>
> It would be better if poss to fix the balancer rather than deprecating it.

to some degree the in kernel balancer cannot really make the level of decisions that a
userspace balancer can make, at least not without making all kernel developers vomit ;)
(for example the userspace balancer looks in /proc/interrupts and parses that to see
which interrupts are used by networking versus which by storage etc, and has different
balancing policies for those and other classes; the networking policy basically comes down to
"pin the interrupt unless some higher networking interrupt really gets in the way")