From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754039Ab3J3Ms1 (ORCPT ); Wed, 30 Oct 2013 08:48:27 -0400 Received: from merlin.infradead.org ([205.233.59.134]:43368 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751803Ab3J3Ms0 (ORCPT ); Wed, 30 Oct 2013 08:48:26 -0400 Date: Wed, 30 Oct 2013 13:48:00 +0100 From: Peter Zijlstra To: James Hogan Cc: Vince Weaver , Victor Kaplansky , Oleg Nesterov , Anton Blanchard , Benjamin Herrenschmidt , Frederic Weisbecker , LKML , Linux PPC dev , Mathieu Desnoyers , Michael Ellerman , Michael Neuling , "Paul E. McKenney" , linux-metag Subject: Re: perf events ring buffer memory barrier on powerpc Message-ID: <20131030124800.GJ16117@laptop.programming.kicks-ass.net> References: <20131028132634.GO19466@laptop.lan> <20131028163418.GD4126@linux.vnet.ibm.com> <20131028201735.GA15629@redhat.com> <20131029102131.GA16117@laptop.programming.kicks-ass.net> <20131029103057.GN2490@laptop.programming.kicks-ass.net> <20131030104246.GH16117@laptop.programming.kicks-ass.net> <5270F21C.3080805@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5270F21C.3080805@imgtec.com> 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 11:48:44AM +0000, James Hogan wrote: > Hi Peter, > > On 30/10/13 10:42, Peter Zijlstra wrote: > > Subject: perf, tool: Add required memory barriers > > > > To match patch bf378d341e48 ("perf: Fix perf ring buffer memory > > ordering") change userspace to also adhere to the ordering outlined. > > > > Most barrier implementations were gleaned from > > arch/*/include/asm/barrier.h and with the exception of metag I'm fairly > > sure they're correct. > > Yeh... > > Short answer: > For Meta you're probably best off assuming > CONFIG_METAG_SMP_WRITE_REORDERING=n and just using compiler barriers. Thanks, fixed it that way. > Long answer: > The issue with write reordering between Meta's hardware threads beyond > the cache is only with a particular SoC, and SMP is not used in > production on it. > It is possible to make the LINSYSEVENT_WR_COMBINE_FLUSH register > writable to userspace (it's in a non-mappable region already) but even > then the write to that register needs odd placement to be effective > (before the shmem write rather than after - which isn't a place any > existing barriers are guaranteed to be placed). I'm fairly confident we > get away with it in the kernel, and userland normally just uses linked > load/store instructions for atomicity which works fine. Urgh.. sounds like way 'fun' for you ;-)