Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2764271pxj; Mon, 31 May 2021 10:09:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxv+th3CN1tEa24GkgGJYi/Hym6NYaWZN4VbmjizLnqoNFbnilKsnUd4XM0z1gKnZpUa9FF X-Received: by 2002:a5e:a704:: with SMTP id b4mr18217384iod.35.1622480954913; Mon, 31 May 2021 10:09:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622480954; cv=none; d=google.com; s=arc-20160816; b=ba40ljO2L4M1XNbHd9uxzBBR6qZovKyl7Keent+VvWRXRGOY5dldI9AhByBl7OZMJR fGHYPsdV6+B2cj5huYVfW/Nb975BBYib8NNvwAhuRW5PNevfhdvVpmJLefoq4mqqdnyu EPubHm6gZ65GUp0J/L+x67Tqf2bZrEfcXt3IuiOCi3scRE/8OTpT4hkFoMqSWT/mvqWA 6HYDdRowHCs4kPR/Ieul2fH1c8LO9Y1+nFlEQ+uXW+0SwCQ0z6/DO0/l0q7d0PfCO8fn /oNsNniPcp/te+TpNEANz7NRt8x5XI5IWSFY6g9WC/dOb3H9qlYVCVAqyjY53NwGs/Yb I7Gw== 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:to:from:date:dkim-signature; bh=ET6uFordsiWwX4MCNMKhRus+C3EuLNdh9eoANIik8+8=; b=JkdZO2ckJxeVRk8mgOvYTpBCRurZtgGTU4ESvjHc46c3j/n2bO1HAOR2W/82OhZEe/ hntodKfdQ7eqaKWeQqh37Xs5ZqDJscbJ1CChBSNGix60m+VGvPD4ocTAvseg7g6Nv2WB rMiFMncAdlshjW1dou4jOBa8xO463zwTzn2zxaBtwtUEKqNcmY9a2K1PooXql6jw7oe6 cN3V5W7EK8ikszyxsjpm0gYQUMe1c742hJX6AGXiPrc+kaTZEin6DJq/TdWIprUCiWVt pQzpOnwBKxGw5aucKyg0+tMcp252zJRDwL8wEDtpKX3jMxXrsbw6smV8bRxYKWrVD7YS bSgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=uxQrV6jJ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g3si15870774jan.54.2021.05.31.10.08.54; Mon, 31 May 2021 10:09:14 -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=@linaro.org header.s=google header.b=uxQrV6jJ; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232102AbhEaRIx (ORCPT + 99 others); Mon, 31 May 2021 13:08:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234004AbhEaQxJ (ORCPT ); Mon, 31 May 2021 12:53:09 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B81B2C08C5F5 for ; Mon, 31 May 2021 08:10:54 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id x18so9207509pfi.9 for ; Mon, 31 May 2021 08:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ET6uFordsiWwX4MCNMKhRus+C3EuLNdh9eoANIik8+8=; b=uxQrV6jJGwTClKvYEfNPzMNvPtOF0xpt3MjLEvYdAfXOqfEmfb8IImhakUa3zkMp9w GoNx9HoqHI6R2jqa89T+r8zAz1WMhF1cjeYu/SzQvv52NEsCZXsdlEgdsdVhEDKSvfzd lzzdZhsik9wljdNu6FTmVNKsAiqEBi9rxNwaa/j24ifcxmMrqGJoA4eiL2ayWkfqaMl2 4vLJffCJ1AvynhPt9UEgyPY07zqAZJ3je3GM62hZsgSY4FHwoMoab9p0un6t6U9WzoiC g8gXwT6xuXjQbdhZK+EPpPHSkxgl4ZexOL6IycLGCPK44Hc5+vdY2ZEBbOskzRjMy7Kt K1ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ET6uFordsiWwX4MCNMKhRus+C3EuLNdh9eoANIik8+8=; b=kdB8ewwV6Fj6u7YrShtEpeKtGR1V6kZ0OtFMfKzJZH+b+QyMsZv8GOsaobujrOlcLL AVPh6wAFPBb0E1LntaYZHR8sxFa4y/3y2q2FNsoelfNVksKcXe//rT6by07JLoptzIU+ HeXEBQNSf+1d6x9Gm6L7uu6pZ4F8Je+aXbcptq8MvIrszBJxzjK4+Uf4O9yaie7T9UJL h93S0fQkqB1uP90D3/r7wTosm6R8VQeIwLhy0hbwlDjYXuPzS3BMHhUqxpvc8KGXMxHR npDPYc33AZPk8uNxKfljdVlsfDwwyUSJpyPQWm5dsbA2S2QXk9AN3jGXMft6rkVQKuZY /tIQ== X-Gm-Message-State: AOAM533EVmjHhxjl6uwuDuE4xMqpKfVZXU05/Qm9McLXYk309rtYzu2U Bmxf/r1k/KRxZPG/Y/fd5+uSr/rkk1HO3Dvq X-Received: by 2002:aa7:8703:0:b029:2da:b87f:7d38 with SMTP id b3-20020aa787030000b02902dab87f7d38mr17753307pfo.20.1622473854083; Mon, 31 May 2021 08:10:54 -0700 (PDT) Received: from leoy-ThinkPad-X240s (ec2-18-167-84-74.ap-east-1.compute.amazonaws.com. [18.167.84.74]) by smtp.gmail.com with ESMTPSA id md24sm1519907pjb.43.2021.05.31.08.10.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 May 2021 08:10:53 -0700 (PDT) Date: Mon, 31 May 2021 23:10:49 +0800 From: Leo Yan To: Arnaldo Carvalho de Melo , Adrian Hunter , Peter Zijlstra , 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 2/2] perf auxtrace: Optimize barriers with load-acquire and store-release Message-ID: <20210531151049.GE9324@leoy-ThinkPad-X240s> References: <20210519140319.1673043-1-leo.yan@linaro.org> <20210519140319.1673043-2-leo.yan@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210519140319.1673043-2-leo.yan@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, Adrian, On Wed, May 19, 2021 at 10:03:19PM +0800, Leo Yan wrote: > Load-acquire and store-release are one-way permeable barriers, which can > be used to guarantee the memory ordering between accessing the buffer > data and the buffer's head / tail. > > This patch optimizes the memory ordering with the load-acquire and > store-release barriers. Is this patch okay for you? Besides this patch, I have an extra question. You could see for accessing the AUX buffer's head and tail, it also support to use compiler build-in functions for atomicity accessing: __sync_val_compare_and_swap() __sync_bool_compare_and_swap() Since now we have READ_ONCE()/WRITE_ONCE(), do you think we still need to support __sync_xxx_compare_and_swap() atomicity? I checked the code for updating head and tail for the perf ring buffer (see ring_buffer_read_head() and ring_buffer_write_tail() in the file tools/include/linux/ring_buffer.h), which doesn't support __sync_xxx_compare_and_swap() anymore. This is why I wander if should drop __sync_xxx_compare_and_swap() atomicity for AUX ring buffer as well. Thanks, Leo