Bug#926967: Don't recommend irqbalance (was: Re: Handling irqbalance in virtual environments)
Package: src:linux
Version: 4.19.28-2
Severity: important
On Fri, Apr 12, 2019 at 09:10:32PM +0100, Ben Hutchings wrote:
> On Fri, 2019-04-12 at 10:53 +0200, Bastian Blank wrote:
> > It turns out we got again problems with irqbalance.
> >
> > It was added as recommends of the main image in 3.16, as it was reported
> > that older kernels move all interrupts to CPU 0 without help.[1]
> >
> > In the meantime the kernel can do balancing on it's own. In 4.9, I've
> > seen it working with aacraid, each queue gets hard pinned to it's own
> > CPU from 0 to $NRCPUS. In 4.19 I've seen the same working properly with
> > virtio-net.
> >
> > With 4.19, even on real hardware, where interrupts have an affinity for
> > all cpus, each interrupt is actually delivered to different cpu.
> >
> > Random example for this, it even selects only one thread of each core:
> >
> > > 26: 0 0 0 0 92 0 0 0 IR-PCI-MSI 3670017-edge eno1-TxRx-0
> > > 27: 0 0 0 0 0 167 0 0 IR-PCI-MSI 3670018-edge eno1-TxRx-1
> > > 28: 0 0 0 0 0 0 467 0 IR-PCI-MSI 3670019-edge eno1-TxRx-2
> > > 29: 0 0 0 0 0 0 0 454 IR-PCI-MSI 3670020-edge eno1-TxRx-3
> >
> > Now irqbalance comes to re-do the existing pinning, and the result is not
> > longer correct but $RANDOM for the hard queue-to-cpu case of virtio.
>
> Then let's drop the recommendation.
Okay.
Regards,
Bastian
--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
Reply to: