From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YclpO-0005YA-H1 for qemu-devel@nongnu.org; Mon, 30 Mar 2015 22:22:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YclpK-0003zD-Pl for qemu-devel@nongnu.org; Mon, 30 Mar 2015 22:22:54 -0400 Received: from ozlabs.org ([103.22.144.67]:33390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YclpK-0003yx-Ef for qemu-devel@nongnu.org; Mon, 30 Mar 2015 22:22:50 -0400 Date: Tue, 31 Mar 2015 13:23:05 +1100 From: David Gibson Message-ID: <20150331022305.GU9908@voom.fritz.box> 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> <55190682.20409@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V2AZ19bMCakBLong" Content-Disposition: inline In-Reply-To: <55190682.20409@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 --V2AZ19bMCakBLong Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 30, 2015 at 10:17:06AM +0200, Paolo Bonzini wrote: >=20 >=20 > 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. >=20 > No, don't. >=20 > And both of you, read docs/atomics.txt. *reads* > "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." >=20 > atomic_read() and atomic_set() provide the same guarantees as > ACCESS_ONCE in the Linux kernel. Ok, having better understood the semantics and intentions of the atomic_* functions in qemu, I withdraw my objection. They do seem like the right primitives for this situation. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --V2AZ19bMCakBLong Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVGgUJAAoJEGw4ysog2bOSsN8P/197aa2a3dA8EdIdTr07+b86 tyR0yNtSMYTiHkjqZrVSl3JMTTIsGdzVBCaPRCfeW9LtQTJj+e+jJ1/KYIZv/pXN bh0eeJmNpY+21PVCjP2aDgYwWM/N6u2qqf2TnFOXpWr60eb4QgAfMPXqHe14pSEY jINtSh2vE7NmA7KnSk98B56rKGWkefGa4UCl5oabmQkdfmKg6C7P6/NT2aUcieYx EUmsxCOxBklKskAQXKV9rkMykwv3aSJQCunvw93vAGvOjcoWoAhmfZqddBLVk8jt K/S4nSd3D1GSuT5qVd3R9iOltLMCMQl9w5QXv+c2/9wyFqlmnD2R6xUdYhfpvy/B In0GwCEaJ4sJzmfeJo3UwzfcT6dRigAgkAmkMGkPPyeA8OiLeluM8T8HbWNihaF+ vsVovoHS/c5mcs1kAAHiBcIelbtFJ9X3D6v8e7IKgDSsL6ixBjm9h/sOBRQCdCm6 8FRIM0N19npfylSBYxFD2obZ/5B/C/Icc/HtTLlTuRiG0ON+ktDufpBohvJQqVRr XP7I2B4MwMYcuhPW9Jf3w3o7NpNfhKamsARBLWeWm/mgjkeT47hKTQCjS7hnEmLX ZUm8jJ08tRykKerMThvzLb875rQylhBzCBYWCtyiefiSYZ6RoDEcMXss6c8UbuEi gIwjceycNYD4xx/k70XI =+dDb -----END PGP SIGNATURE----- --V2AZ19bMCakBLong--