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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8C880CA0FEB for ; Fri, 30 Aug 2024 13:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ds3taXHLyIFX5lQ2SBqgXRv32G3srHGbQ11hJhl9UlU=; b=lZ7StuQdfbnjR+trI0i3lkXqdJ sTs0iGRuB560kloU/13vrDIpOlEXHphNxH708IK2Y1WKgXoyKGNTlFHYjw6VPZksMi0RdPLIB6A9H DtXywTOyjGUHNMnUDcQzYZct99joaVvpxFp1nrTZQZOMLoTZuHIcBBw8sK3H6lYdrDgAgunhmtVpL zWl6x649A1rdexH5Obky8gy95hIhuzk9WN02TTIvpzZddyDuqdA7sfVMk+Lgn9NM3+rgsTYTuuhsJ Xd1rz7ZrNjUkpY3EvTFjtsetiLpLaqKHPGJ70J6It5TFiSHwMkyeeKL0o57OixNXdwEQr/x7y+qHe byS0afcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sk1Yo-00000006OPe-22Hn; Fri, 30 Aug 2024 13:21:06 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sk1Nj-00000006MCS-2wRu for linux-arm-kernel@lists.infradead.org; Fri, 30 Aug 2024 13:09:41 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 88EEBAE4879; Fri, 30 Aug 2024 13:09:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A166BC4CEC2; Fri, 30 Aug 2024 13:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725023377; bh=QvPrz8rzklG+KeLU/RJsKgy+ZZCTvBZD+d/rparHM2I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DbK6IHQ8FV7g+D3kbufxEFgeCXJtCjK4OWJSAOaNNWDl00LvQjd2zwU/I2gBLsEXX YT/N5LrTGs7RTcr106/1li0Fw8K1xc6ncVfrExN4YOmjfNbTMdPQSAl4V921RZwByU uC5tpD4CibZA0uiz9/Dv5rVyk3v0EZkWdu4HRxLefg4bjma8mzJkuE6dUNjvFEhis6 pBMmntwjnqGBrvRN3NdaR5hvx/ShtoE0Grybi7YT34+ePlwgbaeirMAuFHpKNU/UT7 T9oTXErrAMdjmSnlubARe+9YGWl2/XDpmRZ+07Wnr1pBFQptRSrUY0Dvc+6/VJWJVF oR3Ff1NQyH2UQ== Date: Fri, 30 Aug 2024 14:09:31 +0100 From: Will Deacon To: Leo Yan Cc: Arnaldo Carvalho de Melo , Mark Rutland , Suzuki K Poulose , Mike Leach , James Clark , John Garry , Namhyung Kim , Ian Rogers , Adrian Hunter , "Liang, Kan" , Jonathan Cameron , Yicong Yang , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, coresight@lists.linaro.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH v1 1/9] perf: arm_spe: Introduce 'lds' capacity Message-ID: <20240830130930.GA8615@willie-the-truck> References: <20240827164417.3309560-1-leo.yan@arm.com> <20240827164417.3309560-2-leo.yan@arm.com> <20240830103834.GA8000@willie-the-truck> <655edf2e-8e0d-4c00-91a1-1af58593f597@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655edf2e-8e0d-4c00-91a1-1af58593f597@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240830_060940_126384_F3563BB6 X-CRM114-Status: GOOD ( 32.20 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 30, 2024 at 01:12:33PM +0100, Leo Yan wrote: > On 8/30/24 11:38, Will Deacon wrote: > > On Tue, Aug 27, 2024 at 05:44:09PM +0100, Leo Yan wrote: > > > This commit adds a new entry 'lds' in the capacity folder. 'lds' stands > > > for "loaded data source". When its value is 1, it indicates the data > > > source implemented, and data source packets will be recorded in the > > > trace data. > > > > > > Signed-off-by: Leo Yan > > > --- > > > drivers/perf/arm_spe_pmu.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c > > > index 9100d82bfabc..81c1e7627721 100644 > > > --- a/drivers/perf/arm_spe_pmu.c > > > +++ b/drivers/perf/arm_spe_pmu.c > > > @@ -110,6 +110,7 @@ enum arm_spe_pmu_buf_fault_action { > > > /* This sysfs gunk was really good fun to write. */ > > > enum arm_spe_pmu_capabilities { > > > SPE_PMU_CAP_ARCH_INST = 0, > > > + SPE_PMU_CAP_LDS, > > > SPE_PMU_CAP_ERND, > > > SPE_PMU_CAP_FEAT_MAX, > > > SPE_PMU_CAP_CNT_SZ = SPE_PMU_CAP_FEAT_MAX, > > > @@ -118,6 +119,7 @@ enum arm_spe_pmu_capabilities { > > > > > > static int arm_spe_pmu_feat_caps[SPE_PMU_CAP_FEAT_MAX] = { > > > [SPE_PMU_CAP_ARCH_INST] = SPE_PMU_FEAT_ARCH_INST, > > > + [SPE_PMU_CAP_LDS] = SPE_PMU_FEAT_LDS, > > > [SPE_PMU_CAP_ERND] = SPE_PMU_FEAT_ERND, > > > }; > > > > > > @@ -160,6 +162,7 @@ static ssize_t arm_spe_pmu_cap_show(struct device *dev, > > > > > > static struct attribute *arm_spe_pmu_cap_attr[] = { > > > SPE_CAP_EXT_ATTR_ENTRY(arch_inst, SPE_PMU_CAP_ARCH_INST), > > > + SPE_CAP_EXT_ATTR_ENTRY(lds, SPE_PMU_CAP_LDS), > > > SPE_CAP_EXT_ATTR_ENTRY(ernd, SPE_PMU_CAP_ERND), > > > SPE_CAP_EXT_ATTR_ENTRY(count_size, SPE_PMU_CAP_CNT_SZ), > > > SPE_CAP_EXT_ATTR_ENTRY(min_interval, SPE_PMU_CAP_MIN_IVAL), > > > > What will userspace do with this? I don't think you can turn LDS on/off, > > so either you'll get the data source packet or you won't. > > Yes, LDS bit does not work as a switch. > > The tool in the userspace will record the LDS bit into the metadata. During > decoding phase, it reads out the LDS from metadata. Based on it, the perf > tool can know if the data source is supported or not, if yes then decode the > data source packet. Why not just decode a data source packet when you see it? i.e. assume LDS is always set. > Another point is how to decide the data source packet format. Now we maintain > a CPU list for tracking CPU variants which support data source trace. For long > term, I would like the tool can based on hardware feature (e.g. a ID register > in Arm SPE) to decide the data source format, so far it is absent. This is why > LDS bit + CPU list is a more reliable way. See some discussion [1]. Huh. Why would you have a CPU in the list if it _doesn't_ have LDS? If we have to resort to per-CPU decoding, then that's even more of a reason not to have the LDS cap imo. Will