From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D638C47082 for ; Mon, 7 Jun 2021 10:42:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 56E37611C0 for ; Mon, 7 Jun 2021 10:42:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56E37611C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=CLG99huA4kKysyXUf8LWuAyd+SkiOjOALlBTkOSNZxg=; b=Q7my5ptUEdeo9E+7/WIw+XCm4H ynTcD34ex1CGN9k8c4QjqW249c37DHp5pQm/g3jCfGDWSG3ERr3Q4tIYLFa7U2kinVUAIVlLdgZC1 h8bjdydSZn6fQNRFRP3c8GM59F7NX1/av12J04ZwxrJIaLT5BF0rGoMX1JtKsvgkk0zr0TjVcUpwd P9IyXw4Z1znKqqiT7GjL/oFzJ+vKew+pMI9Ei5QbBmsV0qYkkSAPp9inov/jqdezD472gGwccGyMO vURCPHnw5JfKAUWv0+aotB87w3CZCiqlAbYJR9PqDf1wgb+cFkjDZuyUi+WxPHx/TD72pBDk5dj7s VbUnlfVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqCgg-0030jI-Pg; Mon, 07 Jun 2021 10:40:55 +0000 Received: from mga06.intel.com ([134.134.136.31]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqCPr-002sXr-PT for linux-arm-kernel@lists.infradead.org; Mon, 07 Jun 2021 10:23:36 +0000 IronPort-SDR: 9NDoRu3TGYZrZqgcHuPpLzv8sToFm2hehAXf9bu1KThfEB3iejs0HlMfLVRLjS0wJXcJQ/Y8LB TTDgl0RzzArg== X-IronPort-AV: E=McAfee;i="6200,9189,10007"; a="265750750" X-IronPort-AV: E=Sophos;i="5.83,254,1616482800"; d="scan'208";a="265750750" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2021 03:23:30 -0700 IronPort-SDR: 6KMKnIbtqCdKX6P8IKQCGifSJPd27S+5hs7Sg2E/hDInGVq3EvHkHIlOxuDoyPdh33ib2f0jAL Tl6R3qQTFOqA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,254,1616482800"; d="scan'208";a="484727860" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.174]) ([10.237.72.174]) by fmsmga002.fm.intel.com with ESMTP; 07 Jun 2021 03:23:25 -0700 Subject: Re: [PATCH v2 8/8] perf record: Directly bail out for compat case To: Leo Yan Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Thomas Gleixner , x86@kernel.org, "H. Peter Anvin" , Mathieu Poirier , Suzuki K Poulose , Mike Leach , Andi Kleen , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org References: <20210602103007.184993-1-leo.yan@linaro.org> <20210602103007.184993-9-leo.yan@linaro.org> <20210602123847.GE10272@leoy-ThinkPad-X240s> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <96e5fac6-17a2-ea03-9b15-338b84321ecf@intel.com> Date: Mon, 7 Jun 2021 13:23:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210602123847.GE10272@leoy-ThinkPad-X240s> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210607_032331_898926_A40926CA X-CRM114-Status: GOOD ( 23.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/06/21 3:38 pm, Leo Yan wrote: > Hi Adrain, > > On Wed, Jun 02, 2021 at 02:18:47PM +0300, Adrian Hunter wrote: >> On 2/06/21 1:30 pm, Leo Yan wrote: >>> Since the 64-bit atomicity is not promised in 32-bit perf, directly >>> report the error and bail out for this case. >>> >>> Now only applies on x86_64 and Arm64 platforms. >>> >>> Suggested-by: Adrian Hunter >> >> Maybe we can do better for the compat case. >> >> We can assume the upper 32-bits change very seldom, >> and always increase. So for the 'read' case: >> >> u64 first, second, last; >> u64 mask = (u64)((u32)-1) << 32; >> >> do { >> first = READ_ONCE(pc->aux_head); >> rmb(); >> second = READ_ONCE(pc->aux_head); >> rmb(); >> last = READ_ONCE(pc->aux_head); >> } while ((first & mask) != (last & mask)); >> return second; >> >> For the write case, we can cause a fatal error only if the new >> tail has non-zero upper 32-bits. That gives up to 4GiB of data >> before aborting: >> >> if (tail & mask) >> return -1; >> smp_mb(); >> WRITE_ONCE(pc->aux_tail, tail); > > Seems to me, it's pointless to only support aux_head for 64-bit and > support aux_tail for 32-bit. I understand this can be helpful for the > snapshot mode which only uses aux_head, but it still fails to support > the normal case for AUX ring buffer using 64-bit head/tail. I am not sure why you say it is pointless. 'perf record' would still be able to capture up to 4GiB of data. Do you mean you usually capture more than 4GiB of data? I was thinking we would separate out the compat case: #if BITS_PER_LONG == 32 if (kernel_is_64_bit) return compat_auxtrace_mmap__[read_head/write_tail]() #endif So the non-compat cases would not be affected. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel