From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcUsl-0000Mi-Nf for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:17:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcUsg-0006mv-SJ for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:17:15 -0400 Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:37175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcUsg-0006ls-Lh for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:17:10 -0400 Received: by wiaa2 with SMTP id a2so117079938wia.0 for ; Mon, 30 Mar 2015 01:17:10 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <55190682.20409@redhat.com> Date: Mon, 30 Mar 2015 10:17:06 +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> In-Reply-To: <20150319093330.GA2409@work-vm> 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: "Dr. David Alan Gilbert" , David Gibson 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 19/03/2015 10:33, Dr. David Alan Gilbert wrote: >> > But still pointless. Atomicity isn't magic pixie dust; it only makes >> > sense if you're making atomic specific operations that need to be. >> > Simple integer loads and stores are already atomic. Unless at least >> > some of the atomic operations are something more complex, there's >> > really no point to atomically marked operations. > OK, I'll kill it off. No, don't. And both of you, read docs/atomics.txt. "atomic_read() and atomic_set() prevents the compiler from using optimizations that might otherwise optimize accesses out of existence on the one hand, or that might create unsolicited accesses on the other. [...] it tells readers which variables are shared with other threads, and which are local to the current thread or protected by other, more mundane means." atomic_read() and atomic_set() provide the same guarantees as ACCESS_ONCE in the Linux kernel. Paolo