Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756159Ab3J1KCF (ORCPT ); Mon, 28 Oct 2013 06:02:05 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:34101 "EHLO mail-la0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755849Ab3J1KCD (ORCPT ); Mon, 28 Oct 2013 06:02:03 -0400 MIME-Version: 1.0 In-Reply-To: <20131025173749.GG19466@laptop.lan> References: <12083.1382486094@ale.ozlabs.ibm.com> <20131023141948.GB3566@localhost.localdomain> <20131025173749.GG19466@laptop.lan> Date: Mon, 28 Oct 2013 11:02:01 +0100 Message-ID: Subject: Re: perf events ring buffer memory barrier on powerpc From: Frederic Weisbecker To: Peter Zijlstra Cc: Michael Neuling , Benjamin Herrenschmidt , Anton Blanchard , LKML , Linux PPC dev , Victor Kaplansky , Mathieu Desnoyers , Michael Ellerman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1295 Lines: 30 2013/10/25 Peter Zijlstra : > On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote: > I would argue for: > > READ ->data_tail READ ->data_head > smp_rmb() (A) smp_rmb() (C) > WRITE $data READ $data > smp_wmb() (B) smp_mb() (D) > STORE ->data_head WRITE ->data_tail > > Where A pairs with D, and B pairs with C. > > I don't think A needs to be a full barrier because we won't in fact > write data until we see the store from userspace. So we simply don't > issue the data WRITE until we observe it. > > OTOH, D needs to be a full barrier since it separates the data READ from > the tail WRITE. > > For B a WMB is sufficient since it separates two WRITEs, and for C an > RMB is sufficient since it separates two READs. Hmm, I need to defer on you for that, I'm not yet comfortable with picking specific barrier flavours when both write and read are involved in a same side :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/