search for: ladelski

"Michael S. Tsirkin" <mst at redhat.com> wrote on 20/08/2014 01:57:10 PM: > > Results: > > > > Netperf, 1 vm: > > The polling patch improved throughput by ~33% (1516 MB/sec -> 2046 MB/sec). > > Number of exits/sec decreased 6x. > > The same improvement was shown when I tested with 3 vms running netperf > > (4086 MB/sec -> 5545

"Michael S. Tsirkin" <mst at redhat.com> wrote on 20/08/2014 01:57:10 PM: > > Results: > > > > Netperf, 1 vm: > > The polling patch improved throughput by ~33% (1516 MB/sec -> 2046 MB/sec). > > Number of exits/sec decreased 6x. > > The same improvement was shown when I tested with 3 vms running netperf > > (4086 MB/sec -> 5545

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Sun, 10 Aug 2014 21:45:59 +0200 > On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: ... > And, did your tests actually produce 100% load on both host CPUs? ... Michael, please do not quote an entire patch just to ask a one line question. I truly, truly, wish it was simpler in modern email clients to

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Sun, 10 Aug 2014 21:45:59 +0200 > On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: ... > And, did your tests actually produce 100% load on both host CPUs? ... Michael, please do not quote an entire patch just to ask a one line question. I truly, truly, wish it was simpler in modern email clients to

"Michael S. Tsirkin" <mst at redhat.com> wrote on 12/08/2014 12:18:50 PM: > From: "Michael S. Tsirkin" <mst at redhat.com> > To: David Miller <davem at davemloft.net> > Cc: Razya Ladelsky/Haifa/IBM at IBMIL, kvm at vger.kernel.org, Alex > Glikson/Haifa/IBM at IBMIL, Eran Raichstein/Haifa/IBM at IBMIL, Yossi > Kuperman1/Haifa/IBM at IBMIL,

"Michael S. Tsirkin" <mst at redhat.com> wrote on 12/08/2014 12:18:50 PM: > From: "Michael S. Tsirkin" <mst at redhat.com> > To: David Miller <davem at davemloft.net> > Cc: Razya Ladelsky/Haifa/IBM at IBMIL, kvm at vger.kernel.org, Alex > Glikson/Haifa/IBM at IBMIL, Eran Raichstein/Haifa/IBM at IBMIL, Yossi > Kuperman1/Haifa/IBM at IBMIL,

On Tue, Aug 12, 2014 at 01:57:05PM +0300, Razya Ladelsky wrote: > "Michael S. Tsirkin" <mst at redhat.com> wrote on 12/08/2014 12:18:50 PM: > > > From: "Michael S. Tsirkin" <mst at redhat.com> > > To: David Miller <davem at davemloft.net> > > Cc: Razya Ladelsky/Haifa/IBM at IBMIL, kvm at vger.kernel.org, Alex > >

On 10/08/14 10:30, Razya Ladelsky wrote: > From: Razya Ladelsky <razya at il.ibm.com> > Date: Thu, 31 Jul 2014 09:47:20 +0300 > Subject: [PATCH] vhost: Add polling mode > > When vhost is waiting for buffers from the guest driver (e.g., more packets to > send in vhost-net's transmit queue), it normally goes to sleep and waits for the > guest to "kick" it.

From: Razya Ladelsky > "Michael S. Tsirkin" <mst at redhat.com> wrote on 20/08/2014 01:57:10 PM: > > > > Results: > > > > > > Netperf, 1 vm: > > > The polling patch improved throughput by ~33% (1516 MB/sec -> 2046 MB/sec). > > > Number of exits/sec decreased 6x. > > > The same improvement was shown when I tested with 3

From: Razya Ladelsky <razya at il.ibm.com> Date: Thu, 31 Jul 2014 09:47:20 +0300 Subject: [PATCH] vhost: Add polling mode When vhost is waiting for buffers from the guest driver (e.g., more packets to send in vhost-net's transmit queue), it normally goes to sleep and waits for the guest to "kick" it. This kick involves a PIO in the guest, and therefore an exit (and possibly

From: Razya Ladelsky <razya at il.ibm.com> Date: Thu, 31 Jul 2014 09:47:20 +0300 Subject: [PATCH] vhost: Add polling mode When vhost is waiting for buffers from the guest driver (e.g., more packets to send in vhost-net's transmit queue), it normally goes to sleep and waits for the guest to "kick" it. This kick involves a PIO in the guest, and therefore an exit (and possibly

On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: > From: Razya Ladelsky <razya at il.ibm.com> > Date: Thu, 31 Jul 2014 09:47:20 +0300 > Subject: [PATCH] vhost: Add polling mode > > When vhost is waiting for buffers from the guest driver (e.g., more packets to > send in vhost-net's transmit queue), it normally goes to sleep and waits for the > guest to

On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: > From: Razya Ladelsky <razya at il.ibm.com> > Date: Thu, 31 Jul 2014 09:47:20 +0300 > Subject: [PATCH] vhost: Add polling mode > > When vhost is waiting for buffers from the guest driver (e.g., more packets to > send in vhost-net's transmit queue), it normally goes to sleep and waits for the > guest to

On Mon, Aug 11, 2014 at 12:46:21PM -0700, David Miller wrote: > From: "Michael S. Tsirkin" <mst at redhat.com> > Date: Sun, 10 Aug 2014 21:45:59 +0200 > > > On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: > ... > > And, did your tests actually produce 100% load on both host CPUs? > ... > > Michael, please do not quote an entire

On Sun, Aug 17, 2014 at 03:35:39PM +0300, Razya Ladelsky wrote: > > > > > > Hi Michael, > > > > > > Sorry for the delay, had some problems with my mailbox, and I realized > > > > just now that > > > my reply wasn't sent. > > > The vm indeed ALWAYS utilized 100% cpu, whether polling was enabled or > > > > not.

> That was just one example. There many other possibilities. Either > actually make the systems load all host CPUs equally, or divide > throughput by host CPU. > The polling patch adds this capability to vhost, reducing costly exit overhead when the vm is loaded. In order to load the vm I ran netperf with msg size of 256: Without polling: 2480 Mbits/sec, utilization: vm - 100%

> That was just one example. There many other possibilities. Either > actually make the systems load all host CPUs equally, or divide > throughput by host CPU. > The polling patch adds this capability to vhost, reducing costly exit overhead when the vm is loaded. In order to load the vm I ran netperf with msg size of 256: Without polling: 2480 Mbits/sec, utilization: vm - 100%

> > > > Hi Michael, > > > > Sorry for the delay, had some problems with my mailbox, and I realized > > just now that > > my reply wasn't sent. > > The vm indeed ALWAYS utilized 100% cpu, whether polling was enabled or > > not. > > The vhost thread utilized less than 100% (of the other cpu) when polling > > was disabled. >

> > > > Hi Michael, > > > > Sorry for the delay, had some problems with my mailbox, and I realized > > just now that > > my reply wasn't sent. > > The vm indeed ALWAYS utilized 100% cpu, whether polling was enabled or > > not. > > The vhost thread utilized less than 100% (of the other cpu) when polling > > was disabled. >