From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9YZp-0004zr-FP for qemu-devel@nongnu.org; Thu, 17 Dec 2015 08:26:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9YZk-0005vo-PZ for qemu-devel@nongnu.org; Thu, 17 Dec 2015 08:26:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9YZk-0005vZ-LA for qemu-devel@nongnu.org; Thu, 17 Dec 2015 08:26:32 -0500 Date: Thu, 17 Dec 2015 15:26:29 +0200 From: "Michael S. Tsirkin" Message-ID: <20151217151705-mutt-send-email-mst@redhat.com> References: <1450347932-16325-1-git-send-email-mst@redhat.com> <20151217112222.GC6375@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151217112222.GC6375@twins.programming.kicks-ass.net> Subject: Re: [Qemu-devel] [PATCH] virtio_ring: use smp_store_mb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Zijlstra Cc: qemu-devel@nongnu.org, Jason Wang , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org On Thu, Dec 17, 2015 at 12:22:22PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > Seems to give a speedup on my box but I'm less sure about this one. E.g. as > > xchng faster than mfence on all/most intel CPUs? Anyone has an opinion? > > Would help if you Cc people who would actually know this :-) Good point. Glad you still saw this. Thanks! > Yes, we've recently established that xchg is indeed faster than mfence > on at least recent machines, see: > > lkml.kernel.org/r/CA+55aFynbkeuUGs9s-q+fLY6MeRBA6MjEyWWbbe7A5AaqsAknw@mail.gmail.com > > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif > > + { > > + WRITE_ONCE(*p, v); > > + mb(); > > + } > > +} > > Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in > that they use dma_* ops for weak_barriers, while virtio_mb() uses > smp_mb(). It's a hack really. I think I'll clean it up a bit to make it more consistent. To simplify things, you may consider things before the optimization brought in by commit 9e1a27ea42691429e31f158cce6fc61bc79bb2e9 Author: Alexander Duyck Date: Mon Apr 13 21:03:49 2015 +0930 virtio_ring: Update weak barriers to use dma_wmb/rmb > As previously stated, smp_mb() does not cover the same memory domains as > dma_mb() would. I know. We used to consistently do the right thing on SMP, but on UP Linux does not have good portable APIs for us to use. So we hack around with what's available which is typically stronger than what's really needed. I guess no one cares about UP that much. The Alexander came and tried to optimize UP using dma_wmb/dma_rmb. I guess he did not find dma_mb so left it as is. Maybe we should make virtio depend on SMP, and be done with it, but the amount of code to maintain !SMP is small enough to not be worth the potential pain to users (if any). -- MST