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-irq-smp_affinity/ > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
