On Tue, Jul 29, 2014 at 03:23:59PM +0300, Razya Ladelsky wrote: > > > > Hmm there aren't a lot of numbers there :(. Speed increased by 33% but > > by how much? E.g. maybe you are getting from 1Mbyte/sec to 1.3, > > if so it's hard to get excited about it. > > Netperf 1 VM: 1516 MB/sec -> 2046 MB/sec > and for 3 VMs: 4086 MB/sec -> 5545 MB/sec What do you mean by 1 VM? Streaming TCP host to vm? Also, your throughput is somewhat low, it's worth seeing why you can't hit higher speeds. > > Some questions that come to > > mind: what was the message size? I would expect several measurements > > with different values. How did host CPU utilization change? > > > > message size was 64B in order to get the VM to be cpu saturated. > so vhost had 99% cpu and vhost 38%, with the polling patch both had 99%. Hmm so a net loss in throughput/CPU. > > > > What about latency? As we are competing with guest for host CPU, > > would worst-case or average latency suffer? > > > > Polling indeed doesn't make a lot of sense if there aren't enough > available cores. > In these cases polling should not be used. > > Thank you, > Razya OK but scheduler might run vm and vhost on the same cpu even if cores are available. This needs to be detected somehow and polling disabled. > > > > Thanks, > > > > -- > > MST > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
