kvm-owner@xxxxxxxxxxxxxxx wrote on 29/07/2014 03:40:18 PM: > From: "Michael S. Tsirkin" <mst@xxxxxxxxxx> > To: Razya Ladelsky/Haifa/IBM@IBMIL, > Cc: abel.gordon@xxxxxxxxx, Alex Glikson/Haifa/IBM@IBMIL, Eran > Raichstein/Haifa/IBM@IBMIL, Joel Nider/Haifa/IBM@IBMIL, > kvm@xxxxxxxxxxxxxxx, kvm-owner@xxxxxxxxxxxxxxx, Yossi Kuperman1/ > Haifa/IBM@IBMIL > Date: 29/07/2014 03:40 PM > Subject: Re: [PATCH] vhost: Add polling mode > Sent by: kvm-owner@xxxxxxxxxxxxxxx > > 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. > My configuration is this: I have two machines, A and B. A hosts the vms, B runs the netserver. One vm (on A) runs netperf, where the its destination server is running on B. I ran netperf with 64B messages, which is heavily loading the vm, which is why its throughput is low. The idea was to get it 100% loaded, so we can see that the polling is getting it to produce higher throughput. > > > 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. > Actually, my experiments were fair in a sense that for both cases, with or without polling, I run both threads, vcpu and vhost, on 2 cores (set their affinity that way). The only difference was whether polling was enabled/disabled. > > > > > > > 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 > -- 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
