From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 01/15] atomic: introduce atomic operations Date: Wed, 08 Aug 2012 17:00:46 +0300 Message-ID: <5022710E.7070202@redhat.com> References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-2-git-send-email-qemulist@gmail.com> <5022671E.8070602@redhat.com> <50226E76.7000609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Peter Maydell , kvm@vger.kernel.org, Stefan Hajnoczi , Marcelo Tosatti , Liu Ping Fan , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Jan Kiszka , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56083 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753857Ab2HHOBA (ORCPT ); Wed, 8 Aug 2012 10:01:00 -0400 In-Reply-To: <50226E76.7000609@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/08/2012 04:49 PM, Paolo Bonzini wrote: > Il 08/08/2012 15:32, Peter Maydell ha scritto: >>> > 1. GCC atomics look ugly, :) do not provide rmb/wmb, and in some >>> > versions of GCC mb is known to be (wrongly) a no-op. >>> > >>> > 2. glib atomics do not provide mb/rmb/wmb either, and >>> > g_atomic_int_get/g_atomic_int_set are inefficient: they add barriers >>> > everywhere, while it is clearer if you put barriers manually, and you >>> > often do not need barriers in the get side. glib atomics also do not >>> > provide xchg. >> These are arguments in favour of "don't try to use atomic ops" -- >> if serious large projects like GCC and glib can't produce working >> efficient implementations for all target architectures, what chance >> do we have? > > Well, maybe... but the flaws in both GCC and glib are small in size > (even though large in importance, at least for us) and we can work > around them easily. mb/rmb/wmb is essentially the small set of atomic > operations that we're already using. We can easily define rmb()/wmb() to be __sync_synchronize() as a default, and only override them where it matters. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz6oo-00023S-IX for qemu-devel@nongnu.org; Wed, 08 Aug 2012 10:01:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sz6oi-0000JN-M3 for qemu-devel@nongnu.org; Wed, 08 Aug 2012 10:01:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz6oi-0000J6-Cl for qemu-devel@nongnu.org; Wed, 08 Aug 2012 10:00:56 -0400 Message-ID: <5022710E.7070202@redhat.com> Date: Wed, 08 Aug 2012 17:00:46 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-2-git-send-email-qemulist@gmail.com> <5022671E.8070602@redhat.com> <50226E76.7000609@redhat.com> In-Reply-To: <50226E76.7000609@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/15] atomic: introduce atomic operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , kvm@vger.kernel.org, Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Liu Ping Fan , Blue Swirl , Anthony Liguori , Jan Kiszka , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 08/08/2012 04:49 PM, Paolo Bonzini wrote: > Il 08/08/2012 15:32, Peter Maydell ha scritto: >>> > 1. GCC atomics look ugly, :) do not provide rmb/wmb, and in some >>> > versions of GCC mb is known to be (wrongly) a no-op. >>> > >>> > 2. glib atomics do not provide mb/rmb/wmb either, and >>> > g_atomic_int_get/g_atomic_int_set are inefficient: they add barriers >>> > everywhere, while it is clearer if you put barriers manually, and you >>> > often do not need barriers in the get side. glib atomics also do not >>> > provide xchg. >> These are arguments in favour of "don't try to use atomic ops" -- >> if serious large projects like GCC and glib can't produce working >> efficient implementations for all target architectures, what chance >> do we have? > > Well, maybe... but the flaws in both GCC and glib are small in size > (even though large in importance, at least for us) and we can work > around them easily. mb/rmb/wmb is essentially the small set of atomic > operations that we're already using. We can easily define rmb()/wmb() to be __sync_synchronize() as a default, and only override them where it matters. -- error compiling committee.c: too many arguments to function