From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWOaK-0007ik-Pv for qemu-devel@nongnu.org; Mon, 21 May 2012 05:07:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWOaF-0007Lu-VA for qemu-devel@nongnu.org; Mon, 21 May 2012 05:07:24 -0400 Received: from gate.crashing.org ([63.228.1.57]:48885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWOaF-0007HL-K7 for qemu-devel@nongnu.org; Mon, 21 May 2012 05:07:19 -0400 Message-ID: <1337591230.2779.42.camel@pasglop> From: Benjamin Herrenschmidt Date: Mon, 21 May 2012 19:07:10 +1000 In-Reply-To: <1337590688.2779.37.camel@pasglop> References: <1337213257.30558.22.camel@pasglop> <1337214293.30558.25.camel@pasglop> <4FB5F1FD.9020009@redhat.com> <1337329136.2513.7.camel@pasglop> <4FB60EFF.6070205@redhat.com> <1337379992.2513.17.camel@pasglop> <4FB74AB0.7090608@redhat.com> <1337549768.2458.0.camel@pasglop> <1337565405.2458.12.camel@pasglop> <4FB9F89A.90702@redhat.com> <20120521083132.GI4674@redhat.com> <1337590688.2779.37.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory access functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , qemu-devel@nongnu.org, Anthony Liguori , David Gibson On Mon, 2012-05-21 at 18:58 +1000, Benjamin Herrenschmidt wrote: > Except that you mostly don't know at that level what you can or cannot > do, it depends on the caller. We should have the standard accessors do > it the "safe" way and have performance sensitive stuff do map/unmap, at > least that's the result of the discussions with Anthony. > > If we can address the virtqueue_map_sg problem, I think we should be > good, I'll look at it tomorrow. Maybe the right way for now is to remove > the barrier I added to "map" and only leave the one in _rw One thing that might alleviate some of your concerns would possibly be to "remember" in a global (to be replaced with a thread var eventually) the last transfer direction and use a simple test to chose the barrier, ie, store + store -> wmb, load + load -> rmb, other -> mb. But first I'd be curious if some x86 folks could actually measure the impact of the patch as I proposed it. That would give us an idea of how bad the performance problem is and how far we need to go to address it. Cheers, Ben.