Benchmarking for vhost polling patch
Hi Michael,
Quoted 6 lines
Hi Razya,
On the netperf benchmark, it looks like polling=10 gives a modest but measureable gain. So from that perspective it might be worth it if it's not too much code, though we'll need to spend more time checking the macro effect - we barely moved the needle on the macro benchmark and that is suspicious.
I ran memcached with various values for the key & value arguments, and managed to see a bigger impact of polling than when I used the default values, Here are the numbers:
key=250 TPS net vhost vm TPS/cpu TPS/CPU value=2048 rate util util change
polling=0 101540 103.0 46 100 695.47 polling=5 136747 123.0 83 100 747.25 0.074440609 polling=7 140722 125.7 84 100 764.79 0.099663658 polling=10 141719 126.3 87 100 757.85 0.089688003 polling=15 142430 127.1 90 100 749.63 0.077863015 polling=25 146347 128.7 95 100 750.49 0.079107993 polling=50 150882 131.1 100 100 754.41 0.084733701
Macro benchmarks are less I/O intensive than the micro benchmark, which is why we can expect less impact for polling as compared to netperf. However, as shown above, we managed to get 10% TPS/CPU improvement with the polling patch.
Quoted 2 lines
Is there a chance you are actually trading latency for throughput? do you observe any effect on latency?
No.
Quoted 2 lines
How about trying some other benchmark, e.g. NFS?
Tried, but didn't have enough I/O produced (vhost was at most at 15% util)
Quoted 8 lines
Also, I am wondering:
since vhost thread is polling in kernel anyway, shouldn't we try and poll the host NIC?
that would likely reduce at least the latency significantly, won't it?
Yes, it could be a great addition at some point, but needs a thorough investigation. In any case, not a part of this patch...
Thanks,
Razya