Thread (42 messages) flat view 42 messages, 5 authors, 2017-11-28

Re: Regression in throughput between kvm guests over virtual bridge

From: Matthew Rosato <hidden>
Date: 2017-09-20 19:38:29

Seems to make some progress on wakeup mitigation. Previous patch tries
to reduce the unnecessary traversal of waitqueue during rx. Attached
patch goes even further which disables rx polling during processing tx.
Please try it to see if it has any difference.
Unfortunately, this patch doesn't seem to have made a difference.  I
tried runs with both this patch and the previous patch applied, as well
as only this patch applied for comparison (numbers from vhost thread of
sending VM):

4.12    4.13     patch1   patch2   patch1+2
2.00%   +3.69%   +2.55%   +2.81%   +2.69%   [...] __wake_up_sync_key

In each case, the regression in throughput was still present.
And two questions:
- Is the issue existed if you do uperf between 2VMs (instead of 4VMs)
Verified that the second set of guests are not actually required, I can
see the regression with only 2 VMs.
- Can enable batching in the tap of sending VM improve the performance
(ethtool -C $tap rx-frames 64)
I tried this, but it did not help (actually seemed to make things a
little worse)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help