On Fri, Apr 12, 2019 at 10:56:29PM +0200, Bastian Blank 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. +1 ! On what appears to be a related note, irqbalance + linux-4.19 appears to cause a 1.5-to-2.5w power regression on my Thinkpad X220 vs irqbalance + linux-4.9, even when no VMs are running. Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature