From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWwpE-0003Ju-ET for qemu-devel@nongnu.org; Tue, 22 May 2012 17:41:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWwpC-0001BL-CY for qemu-devel@nongnu.org; Tue, 22 May 2012 17:41:04 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:57311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWwpC-00019P-6b for qemu-devel@nongnu.org; Tue, 22 May 2012 17:41:02 -0400 Received: by pbbro12 with SMTP id ro12so10757900pbb.4 for ; Tue, 22 May 2012 14:41:00 -0700 (PDT) Message-ID: <4FBC07E6.80305@codemonkey.ws> Date: Tue, 22 May 2012 16:40:54 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <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> <20120522111441.GC3032@redhat.com> <1337686901.3038.12.camel@pasglop> <20120522120358.GA3504@redhat.com> In-Reply-To: <20120522120358.GA3504@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: Rusty Russell , David Gibson , qemu-devel@nongnu.org, Paolo Bonzini On 05/22/2012 07:03 AM, Michael S. Tsirkin wrote: > On Tue, May 22, 2012 at 09:41:41PM +1000, Benjamin Herrenschmidt wrote: >> On Tue, 2012-05-22 at 14:14 +0300, Michael S. Tsirkin wrote: >>>> 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. >> >> The simple fact that we don't reach the baseline while in qemu seems to >> be a reasonably good indication that we tend to be CPU bound already so >> it's not -that- relevant. It would be if we were saturating the network. >> >> But yes, I can try to do more tests tomorrow, it would be nice if you >> could contribute a proper test protocol (or even test on some machines) >> since you seem to be familiar with those measurements (and I have a very >> limited access to x86 gear ... basically just my laptop). >> >> Cheers, >> Ben. > > I have a deja vu. Amos sent perf results when you argued about > exactly the same issue in guest virtio. Delta was small but > measureable. At the moment I have no free time or free hardware > to redo the same work all over again. It's a well known fact that > actual memory barrier is slow on x86 CPUs. You can't see > it with network on your laptop? Write a microbenchmark. The latest patch doesn't put a barrier in map(). I have an extremely hard time believing anything that uses _rw is going to be performance sensitive. There is a correctness problem here. I think it's important that we fix that and then we can focus on improving performance later. Regards, Anthony Liguori >