From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [PATCH 3/3] kvm-s390: streamline memslot handling - rebased Date: Mon, 08 Jun 2009 14:05:47 +0200 Message-ID: <4A2CFE9B.6020300@linux.vnet.ibm.com> References: <1243952771-32428-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1243952771-32428-4-git-send-email-ehrhardt@linux.vnet.ibm.com> <20090605205312.GA13471@amt.cnet> <4A2CED2E.6030904@linux.vnet.ibm.com> <4A2CF1A2.8090904@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , kvm@vger.kernel.org, borntraeger@de.ibm.com, cotte@de.ibm.com, heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com To: Avi Kivity Return-path: Received: from mtagate7.de.ibm.com ([195.212.29.156]:48015 "EHLO mtagate7.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754748AbZFHMGe (ORCPT ); Mon, 8 Jun 2009 08:06:34 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.14.3/8.13.8) with ESMTP id n58C5p6Z660886 for ; Mon, 8 Jun 2009 12:05:51 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58C5pSp2556006 for ; Mon, 8 Jun 2009 14:05:51 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n58C5pLM031213 for ; Mon, 8 Jun 2009 14:05:51 +0200 In-Reply-To: <4A2CF1A2.8090904@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Christian Ehrhardt wrote: =20 >>> >>> Really need that smp_mb__after_clear_bit ? AFAIK test_and_clear_bit >>> implies a barrier? >>> =20 >> >> Well I agree that practically test_and_clear_bit has a barrier on=20 >> s390, but as far as I read Documentation/atomic_ops.txt at line=20 >> 339-360 I think the interface does not imply it so I wanted to add i= t=20 >> explicitly. I would be happy if someone really knows the in depth=20 >> details here and corrects me :-) > > IIUC rmw bitops are full memory barriers. The non-rmw (from the=20 > caller's perspective), clear_bit() and set_bit(), are not. > > Ok, as the real implementation has one + memory-barriers.txt describing= =20 it with barrier and finally include/asm-generic/bitops/atomic.h=20 descirbes it that way too I think I can drop the explicit smb_wb from m= y=20 patch in the next update (I wait a bit to give the discussion about the= =20 wati/bits a bit more time). Hmm ... would that be worth a clarifying patch to atomic_ops.txt that=20 confused me in the first place ? --=20 Gr=FCsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization=20