irqbalance causes ksoftirqd to use 100% CPU

[joosters]

Binary package hint: irqbalance

irqbalance-0.55-2 seems to misconfigure my Linux box. I have a Sun 4100M2 (2xdual core AMD Opteron 2216) running Ubuntu Hardy (64 bit). I have been benchmarking software that performs lots of network I/O, using 8 network cards on the box (6xe1000 2xforcedeth)

With irqbalance running as a daemon, when the benchmark is under way, there are always two ksoftirqd processes running, each consuming 100% CPU. This unsurprisingly causes a massive slowdown in the benchmark. I can achieve about 4GBits of traffic in total.

I've found two ways of fixing the problem:

1) Kill irqbalance completely before the benchmark runs, OR run irqbalance at bootup with its --oneshot option.
2) Downgrade to irqbalance-0.12-2 from Debian. This version chosen simply because I have used this same machine with a pure Debian installation in the past, and that was the irqbalance on there.

With either of these two steps, throughput rises to about 8GBits and there are no ksoftirqd processes eating CPU. Solution 2 gives slightly better performance, presumably because irqbalance is able to move IRQs around as needed. I would prefer to have an irqbalance running, because while the benchmark has regular network traffic on all NICs, in 'real world' use this machine could have unpredictable network traffic and the initial IRQ allocations may not be optimal.

Running on kernel linux-image-2.6.24-amd64-generic (various versions have failed to make a difference to the behaviour, so I suspect the problem is irqbalance-specific rather than kernel-specific)

[joosters (x-launchpad-slimyhorror-com)]

I've attached a trace of irqbalance while my benchmark test is underway. Also, I should a detail to the original bug: Killing irqbalance only works if you kill it before the benchmark has ever run. If you kill it later on (e.g. before running another benchmark run) then the damage is done and you get ksoftirqd processes spinning as before.

[joosters (x-launchpad-slimyhorror-com)]

I've got a couple potentially more useful traces.

The first is a strace of irqbalance-0.12, starting from a fresh reboot with the irqbalance init script disabled (so the trace shows the first time that irqbalance started messing with the IRQs). The trace continues while the benchmark is run.

I also have a similar trace of irqbalance-0.55, again from a fresh reboot, which I'll attach to this bug. The traces are quite large, sorry!

[Chuck Short (zulcss)]

Hi,

I was wondering if you were still having this problem?

Regards
chuck

[Chuck Short (zulcss)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!