From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/5] Add a global synchronization point for pvclock Date: Mon, 19 Apr 2010 17:37:46 +0300 Message-ID: <4BCC6ABA.9030006@redhat.com> References: <1271356648-5108-1-git-send-email-glommer@redhat.com> <1271356648-5108-2-git-send-email-glommer@redhat.com> <4BCA026D.3070309@redhat.com> <4BCA02D1.2020608@redhat.com> <1271673836.1674.757.camel@laptop> <4BCC34DF.6030702@redhat.com> <1271674575.1674.793.camel@laptop> <4BCC3AC2.8050601@redhat.com> <1271675983.1674.853.camel@laptop> <20100419143219.GF14158@mothafucka.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Zijlstra , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jeremy Fitzhardinge , Marcelo Tosatti , Zachary Amsden To: Glauber Costa Return-path: In-Reply-To: <20100419143219.GF14158@mothafucka.localdomain> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 04/19/2010 05:32 PM, Glauber Costa wrote: > >> Right, another option is to put the initial read outside of the loop, >> that way you'll have the best of all cases, a single LOCK'ed op in the >> loop, and only a single LOCK'ed op for the fast path on sensible >> architectures ;-) >> >> last = atomic64_read(&last_value); >> > isn't a barrier enough here? > > No. On i386, the statement last = last_value; will be split by the compiler into two 32-bit loads. If a write (atomic, using cmpxchg) on another cpu happens between those two loads, then the variable last will have a corrupted value. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.