On Wed, Apr 05, 2017 at 05:29:23PM -0000, I AM USER wrote:
Here is my askfedora post that didn't receive any reply.
https://ask.fedoraproject.org/en/question/103915/what-kernel-relates-to-i...
Description of the problem:
In a network test setup, FC-23 (kernel-4.8) acts as bridge passing network traffic. TCP
iperf tests are done from external (to the hypervisor) servers and clients for throughput
700Mbps. The bridge setup on the hypervisor is done through openvswitch and the VM relies
on those bridge to pass traffic. Number of CPU core assigned to the FC VM is 2.
Two test cases considered:
#1) irqbalance not running
#2) irqbalance running
For test#1, CPU usage seen for the qemu-pid on the hypervisor stays close to 100%
For test#2, CPU usage seen for the qemu-pid on the hypervisor goes to 200%, sometimes
even more.
For test#1, `smp_affinity` uses default value 3, where as for #2, it uses different
values for three different virtio-input interrupts, 1,1,2.
Question is, why turning on irqbalance (default for FC installation) makes it worse ?
Well, first and foremost, just because you have higher cpu utilization doesn't
actually mean things are 'worse' - the first question I would ask is, are you
getting better throughput with irqbalance on than with it off.
That said, given what you describe, and assuming that throughput is unchanged,
I'd guess that you are (a) not using sriov (i.e. your using virtio or some other
bridged virtual ethernet, for which some irq semantics are not what you would
commonly expect, and (b) are not using cpu pinning, which means every time you
try to generate an interrupt directed toward that guest, you may be doing it on
a different cpu, which is the antithesis of what irqbalance hopes to achieve.
Long story short, given what your setup seems to be, you should disable
irqbalance in the guest, theres no need for you to assign interrupt affinity, if
you don't have a stable mapping of vcpu to real cpus.
Neil
> _______________________________________________
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org