From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcUvS-0001ab-IC for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:20:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcUvO-0007dn-IR for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:20:02 -0400 Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:37533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcUvO-0007dU-Bh for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:19:58 -0400 Received: by wiaa2 with SMTP id a2so117191181wia.0 for ; Mon, 30 Mar 2015 01:19:57 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5519072A.5060407@redhat.com> Date: Mon, 30 Mar 2015 10:19:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1424883128-9841-1-git-send-email-dgilbert@redhat.com> <1424883128-9841-24-git-send-email-dgilbert@redhat.com> <20150313012652.GB11973@voom.redhat.com> <20150313111905.GC2486@work-vm> <20150316062355.GG5741@voom.redhat.com> <20150318175951.GL2355@work-vm> <20150319041830.GU5741@voom.redhat.com> <20150319093330.GA2409@work-vm> <20150323022042.GF25043@voom.fritz.box> In-Reply-To: <20150323022042.GF25043@voom.fritz.box> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com, yanghy@cn.fujitsu.com On 23/03/2015 03:20, David Gibson wrote: >>> 1) There's no barrier after the write, so there's no guarantee >>> the other thread will eventually see it (in practice we've got >>> other pthread ops we take so we will get a barrier somewhere, >>> and most CPUs eventually do propagate the store). > Sorry, I should have been clearer. If you need a memory barrier, > by all means include a memory barrier. But that should be > explicit: atomic set/read operations often include barriers, but > it's not obvious which side will include what barrier. Memory barriers are not needed here. The variable is set independently from every other set. There's no ordering. atomic_read/atomic_set do not provide sequential consistency. That's ensured instead by atomic_mb_read/atomic_mb_set (and you're right that it's not obvious which side will include barriers, so you have to use the two together). >>> 2) The read side could legally be optimised out of the loop by >>> the compiler. (but in practice wont be because compilers won't >>> optimise that far). > That one's a trickier question. Compilers are absolutely capable > of optimizing that far, *but* the C rules about when it's allowed > to assume in-memory values remain unchanged are pretty > conservative. I think any function call in the loop will require > it to reload the value, for example. That said, a (compiler only) > memory barrier might be appropriate to ensure that reload. That's exactly what atomic_read provides. Paolo