Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp403148pxj; Thu, 27 May 2021 03:03:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxAYT6yf1p82A3DTZQJCQN5QK4DtLjQVndS5hy6gbBVqZKxeYaW2Ndt0XYA474Q7ARtc5Xx X-Received: by 2002:a05:6402:14c1:: with SMTP id f1mr3131036edx.334.1622109785616; Thu, 27 May 2021 03:03:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622109785; cv=none; d=google.com; s=arc-20160816; b=byO3K+kYtrqXVxpysArzBTd+PsuQaqoMYQVLH1kS059kyh7uBhv7OVt06QYv3mXV5F Vz5u+YmMuNy0/tG+s90OMzzdPTeaV4U8U+9CrJ0uc9m5TIPdRr06jOTxFDWv1Q1DBt6K 5wtpPy+bzPvxMHK8kBrcXxqoaz/Oz3ockOEyjDr1TlW4GkQDZHUQz6HuxgPeZ+XWNPfH 51023XGvFWSbZOC3rqmfgFUCE1qk2yQ08HIchZ1IpC+OEKZWd3kD9HPwXUtFHXoX7wZ3 CQ4tyhX3XkeiuX+bME7UhPMUcAZkx7aiCkHYLjctm1D4uxWqoEKr242UFrNCOzESVt0v uOFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=M06BuFAj4yuWOZYB2BCUAwndvtEu3fLzqS5XWt/dw1o=; b=sZ6DGibcS+W4FdYegKiFXIZRQkzOQ7FbG8Qf3pbP/s3GXnsg4Vj2V6YQC6euUHPafR 93K8IU5hR9z5NrVRv+TEgTDKlr77kMHacK5YQNJ6UwJAul7gm2HquEyoD0GQ17szOuop 7f1Os71EMroHmqhH0nMunP7oaGmmqG4BU48116mHMlo6viUgp1T9P0LjMItO2dh1Z9rN ORPeGA2Q0wCvv5hOqgTqdvKGN6fw6/nOk1rcByNOnP7Gp3YnaSCi8fOeWbg6stQm6DIH obFP+X1aR/nKvPtaIuPADCae9LqtkAPmWAuJuSSVrOjkxIxQF1J6TIbVp1z2ivWqVuez my1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=t8bjjiP2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n24si1493728eds.571.2021.05.27.03.02.42; Thu, 27 May 2021 03:03:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=t8bjjiP2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236023AbhE0KAE (ORCPT + 99 others); Thu, 27 May 2021 06:00:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235867AbhE0KAE (ORCPT ); Thu, 27 May 2021 06:00:04 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83C92C061574; Thu, 27 May 2021 02:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=M06BuFAj4yuWOZYB2BCUAwndvtEu3fLzqS5XWt/dw1o=; b=t8bjjiP2YWixI4qv9xTsJdH7nJ gux/gd6vQ+nWycY8df/tUys7eGrbt1hG/Zsa6F90elOPyVGgLy3ddY+eSpV+vN/TiqJHzbp7HANcI YW7E9PXf3oyyc8xmHgDtT+WFgiw8QY9Z9566L34iSCd3+9jmm5j4kHGscS+1OWFBzLTaEe1wKkCHD GSopVMDMYAOIatIPWNaUKcq5vJlJArT0h7gy3zmXkOFZ3E1KqtW9DUuwsALNY754tNRhlXHjIm9FH GJCnS0LvYfXBBHRVvcppMz1qQza0zSp+bFSjO7NG95ELKg4+mkhZ//X1jKz+okgPXD8IPw6RrVMU5 Vih36JkQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lmCll-005PLs-TW; Thu, 27 May 2021 09:57:44 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 72DA730022C; Thu, 27 May 2021 11:57:37 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 38669200D3A72; Thu, 27 May 2021 11:57:37 +0200 (CEST) Date: Thu, 27 May 2021 11:57:37 +0200 From: Peter Zijlstra To: Adrian Hunter Cc: Leo Yan , Arnaldo Carvalho de Melo , Ingo Molnar , Mark Rutland , Alexander Shishkin , Namhyung Kim , Andi Kleen , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers Message-ID: References: <20210519140319.1673043-1-leo.yan@linaro.org> <3c7dcd5d-fddd-5d3b-81ac-cb7b615b0338@intel.com> <7cdc3578-a50e-89ef-477a-3dc1f84f96bb@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7cdc3578-a50e-89ef-477a-3dc1f84f96bb@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 27, 2021 at 12:24:15PM +0300, Adrian Hunter wrote: > > If all we want is a compiler barrier, then shouldn't that be what we use? > > i.e. barrier() > > I guess you are saying we still need to stop potential re-ordering across > CPUs, so please ignore my comments. Right; so the ordering issue is real, consider: CPU0 (kernel) CPU1 (user) write data read head smp_wmb() smp_rmb() write head read data Without explicit ordering (on either side), we might either read data that isn't written yet: ,--(read data) write data | smp_wmb() | write head ---. | `--> | read head `- read data Where the head load observes the new head writte, but the data load is speculated and loads data before it is written. Or, we can write the head before the data write is visible: ,-- write data | write head | read head | smp_rmb() | read data `-> (data visible) Where we read the head head, but still observe stale data because the stores got committed out of order. x86 is TSO, so neither reordering is actually possible, hence both barriers being a compiler barrier (to ensure the compiler doesn't reorder them for us). But weaker hardware *will* allow those orderings and we very much need actual barriers there. Welcome to the magical world of memory ordering and weak architectures.