From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752180Ab3J3Pjz (ORCPT ); Wed, 30 Oct 2013 11:39:55 -0400 Received: from merlin.infradead.org ([205.233.59.134]:47225 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751377Ab3J3Pjy (ORCPT ); Wed, 30 Oct 2013 11:39:54 -0400 Date: Wed, 30 Oct 2013 16:39:31 +0100 From: Peter Zijlstra To: Victor Kaplansky Cc: Anton Blanchard , Benjamin Herrenschmidt , Frederic Weisbecker , LKML , Linux PPC dev , Mathieu Desnoyers , Michael Ellerman , Michael Neuling , Oleg Nesterov , "Paul E. McKenney" Subject: Re: perf events ring buffer memory barrier on powerpc Message-ID: <20131030153931.GM16117@laptop.programming.kicks-ass.net> References: <20131025173749.GG19466@laptop.lan> <20131028132634.GO19466@laptop.lan> <20131028163418.GD4126@linux.vnet.ibm.com> <20131028201735.GA15629@redhat.com> <20131030092725.GL4126@linux.vnet.ibm.com> <20131030112526.GI16117@laptop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 30, 2013 at 04:52:05PM +0200, Victor Kaplansky wrote: > Peter Zijlstra wrote on 10/30/2013 01:25:26 PM: > > > Also, I'm not entirely sure on C, that too seems like a dependency, we > > simply cannot read the buffer @tail before we've read the tail itself, > > now can we? Similarly we cannot compare tail to head without having the > > head read completed. > > No, this one we cannot omit, because our problem on consumer side is not > with @tail, which is written exclusively by consumer, but with @head. Ah indeed, my argument was flawed in that @head is the important part. But we still do a comparison of @tail against @head before we do further reads. Although I suppose speculative reads are allowed -- they don't have the destructive behaviour speculative writes have -- and thus we could in fact get reorder issues. But since it is still a dependent load in that we do that @tail vs @head comparison before doing other loads, wouldn't a read_barrier_depends() be sufficient? Or do we still need a complete rmb? > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only > around > @head read. Agreed, the ACCESS_ONCE() around tail is superfluous since we're the one updating tail, so there's no problem with the value changing unexpectedly. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B2C6A2C0393 for ; Thu, 31 Oct 2013 02:39:52 +1100 (EST) Date: Wed, 30 Oct 2013 16:39:31 +0100 From: Peter Zijlstra To: Victor Kaplansky Subject: Re: perf events ring buffer memory barrier on powerpc Message-ID: <20131030153931.GM16117@laptop.programming.kicks-ass.net> References: <20131025173749.GG19466@laptop.lan> <20131028132634.GO19466@laptop.lan> <20131028163418.GD4126@linux.vnet.ibm.com> <20131028201735.GA15629@redhat.com> <20131030092725.GL4126@linux.vnet.ibm.com> <20131030112526.GI16117@laptop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: Michael Neuling , Mathieu Desnoyers , LKML , Oleg Nesterov , Linux PPC dev , Anton Blanchard , Frederic Weisbecker , "Paul E. McKenney" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Oct 30, 2013 at 04:52:05PM +0200, Victor Kaplansky wrote: > Peter Zijlstra wrote on 10/30/2013 01:25:26 PM: > > > Also, I'm not entirely sure on C, that too seems like a dependency, we > > simply cannot read the buffer @tail before we've read the tail itself, > > now can we? Similarly we cannot compare tail to head without having the > > head read completed. > > No, this one we cannot omit, because our problem on consumer side is not > with @tail, which is written exclusively by consumer, but with @head. Ah indeed, my argument was flawed in that @head is the important part. But we still do a comparison of @tail against @head before we do further reads. Although I suppose speculative reads are allowed -- they don't have the destructive behaviour speculative writes have -- and thus we could in fact get reorder issues. But since it is still a dependent load in that we do that @tail vs @head comparison before doing other loads, wouldn't a read_barrier_depends() be sufficient? Or do we still need a complete rmb? > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only > around > @head read. Agreed, the ACCESS_ONCE() around tail is superfluous since we're the one updating tail, so there's no problem with the value changing unexpectedly.