From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWnGM-0003eG-Cr for qemu-devel@nongnu.org; Tue, 22 May 2012 07:28:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWnGE-0003iv-P3 for qemu-devel@nongnu.org; Tue, 22 May 2012 07:28:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWnGE-0003ic-HJ for qemu-devel@nongnu.org; Tue, 22 May 2012 07:28:18 -0400 Date: Tue, 22 May 2012 14:14:41 +0300 From: "Michael S. Tsirkin" Message-ID: <20120522111441.GC3032@redhat.com> References: <1337549768.2458.0.camel@pasglop> <1337565405.2458.12.camel@pasglop> <4FB9F89A.90702@redhat.com> <20120521083132.GI4674@redhat.com> <4FBABF2D.2020200@codemonkey.ws> <1337639166.2779.117.camel@pasglop> <4FBAC22A.5010708@codemonkey.ws> <20120521224436.GL17031@redhat.com> <1337661278.2779.166.camel@pasglop> <1337671059.2779.188.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337671059.2779.188.camel@pasglop> Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to DMA functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Paolo Bonzini , Rusty Russell , qemu-devel@nongnu.org, Anthony Liguori , David Gibson On Tue, May 22, 2012 at 05:17:39PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2012-05-22 at 14:34 +1000, Benjamin Herrenschmidt wrote: > > The emulated devices can run simultaneously with the guest, so > > we need to be careful with ordering of load and stores done by > > them to the guest system memory, which need to be observed in > > the right order by the guest operating system. > > > > This adds a barrier call to the basic DMA read/write ops which > > is currently implemented as a smp_mb(), but could be later > > improved for more fine grained control of barriers. > > > > Additionally, a _relaxed() variant of the accessors is provided > > to easily convert devices who would be performance sensitive > > and negatively impacted by the change. > > > > Signed-off-by: Benjamin Herrenschmidt > > --- > > (Note to Rusty: The number I told you on ST is wrong, see below) > > So I tried to do some performance measurements with that patch using > netperf on an x86 laptop (x220 with core i7). > > It's a bit tricky. For example, if I just create a tap interface, > give it a local IP on the laptop and a different IP on the guest, > (ie talking to a netserver on the host basically from the guest > via tap), the performance is pretty poor and the numbers seem > useless with and without the barrier. > > So I did tests involving talking to a server on our gigabit network > instead. > > The baseline is the laptop without kvm talking to the server. The > TCP_STREAM test results are: It's not a good test. The thing most affecting throughput results is how much CPU does you guest get. So as a minumum you need to measure CPU utilization on the host and divide by that. -- MST