From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcuEb-0002Zl-1N for qemu-devel@nongnu.org; Tue, 31 Mar 2015 07:21:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcuEW-000279-2C for qemu-devel@nongnu.org; Tue, 31 Mar 2015 07:21:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcuEV-00026a-PR for qemu-devel@nongnu.org; Tue, 31 Mar 2015 07:21:23 -0400 Date: Tue, 31 Mar 2015 12:21:10 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150331112109.GB7687@work-vm> References: <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> <5519072A.5060407@redhat.com> <20150330170406.GF2474@work-vm> <5519A292.4030808@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5519A292.4030808@redhat.com> 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: Paolo Bonzini Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , amit.shah@redhat.com, yanghy@cn.fujitsu.com, David Gibson * Paolo Bonzini (pbonzini@redhat.com) wrote: > > > On 30/03/2015 19:04, Dr. David Alan Gilbert wrote: > >>> > > 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. > > So does that say I need the atomic_read but not the atomic_write - > > which seems a bit weird, but I think only due to the naming. > > No, you need both even though it's even more far-fetched that the > compiler will do something bad with the set. OK, done - it's back to where it was with atomic_set/atomic_read. Dave > > Paolo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK