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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 7C75AC34026 for ; Tue, 18 Feb 2020 17:08:23 +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 4C1A120801 for ; Tue, 18 Feb 2020 17:08:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ANtgXMLq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C1A120801 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QwJD7gCIDh/NS+5I61NrgdOBUZpunTfrY2BlfUACQX8=; b=ANtgXMLqRPQuz3 JeDb9MpHTAZhDwfEA15l4GB0VBC716QExHdYQkes5UJIuq7tbpJTKp5CiF0pdYT0OnLY3t20nQ9os f4osXPUNxEdizx4avcfAvkg0G2dVym/266X/Fi02Kav0q2HTSy8mXD0FJzKZ1Yxls2EgS1OFu5gYP two9bWNgqYtqbGli+KMYLDER+qCFjmlIs2j3jmBoVA972kjdrX6bYC5sQqVs9ij6m709SiRSic2Xz gBCHBSqj/Fv1ck09fB75bmYYLIm8JQcpp4JcFbGxnG0S5YDAWFsfKmQ6Xgk92sWqRl6vt28GpMhMO QulDudDGkJIghYdFztng==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j46M3-00087M-Pz; Tue, 18 Feb 2020 17:08:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j46M1-00086T-5v for linux-arm-kernel@lists.infradead.org; Tue, 18 Feb 2020 17:08:14 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AFF7731B; Tue, 18 Feb 2020 09:08:10 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9A9DF3F703; Tue, 18 Feb 2020 09:08:08 -0800 (PST) Date: Tue, 18 Feb 2020 17:08:03 +0000 From: Mark Rutland To: John Garry Subject: Re: [PATCH RFC 0/7] perf pmu-events: Support event aliasing for system PMUs Message-ID: <20200218170803.GA9968@lakrids.cambridge.arm.com> References: <1579876505-113251-1-git-send-email-john.garry@huawei.com> <20200218125707.GB20212@willie-the-truck> <20200218133943.GF20212@willie-the-truck> <627cbc50-4b36-7f7f-179d-3d27d9e0215a@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <627cbc50-4b36-7f7f-179d-3d27d9e0215a@huawei.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200218_090813_309827_0872B6E3 X-CRM114-Status: GOOD ( 27.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ak@linux.intel.com, Joakim Zhang , suzuki.poulose@arm.com, peterz@infradead.org, Will Deacon , linuxarm@huawei.com, acme@kernel.org, linux-kernel@vger.kernel.org, zhangshaokun@hisilicon.com, alexander.shishkin@linux.intel.com, mingo@redhat.com, james.clark@arm.com, namhyung@kernel.org, jolsa@redhat.com, linux-arm-kernel@lists.infradead.org, robin.murphy@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 18, 2020 at 04:19:32PM +0000, John Garry wrote: > > > > > > > Why don't we just expose SMMU_IIDR in the SMMUv3 PMU directory, so that > > > > you can key off that? > > > > > > That does not sound like a standard sysfs interface. > > > > It's standard in the sense that PMUs already have their own directory under > > sysfs where you can put things. > > Sure, but then the perf tool will need to be able to interpret all these > custom PMU files, which has scalability issues. > > Maybe this would work and I did consider it, but another concern is that the > PMU drivers will have problems making available some implementation-specific > identifier at all. > > For example, the "caps" directory is a > > dumping ground for all sorts of PMU-specific information. > > > > On the other hand, saying "please go figure out which SoC you're on" > > certainly isn't standard and is likely to lead to unreliable, spaghetti > > code. > > I'm not sure how. The perf tool PMU event aliasing already takes a few > certain steps to figure out which cpuid to use: > > static char *perf_pmu__getcpuid(struct perf_pmu *pmu) > { > char *cpuid; > static bool printed; > > cpuid = getenv("PERF_CPUID"); > if (cpuid) > cpuid = strdup(cpuid); > if (!cpuid) > cpuid = get_cpuid_str(pmu); > if (!cpuid) > return NULL; > > if (!printed) { > pr_debug("Using CPUID %s\n", cpuid); > printed = true; > } > return cpuid; > } > > And this would be something similar - just read some sysfs file. > > > > > > Anyway, I don't think that works for every case, quoting from > > > https://lkml.org/lkml/2019/10/16/465: > > > > > > "> Note: I do acknowledge that an overall issue is that we assume all PMCG > > > IMP DEF events are same for a given SMMU model. > > > > > > That assumption does technically fail already - I know MMU-600 has > > > different IMP-DEF events for its TCU and TBUs, however as long as we can > > > get as far as "this is some part of an MMU-600" the driver should be > > > able to figure out the rest ..." > > > > Perhaps I'm misreading this, but it sounds like if you knew it was an > > MMU-600 then you'd be ok. I also don't understand how a SoC ID makes things > > any easier in this regard. > > It's doesn't necessarily make things easier in this regard. But using a SoC > ID is an alternative to checking the SMMU_ID or the kernel driver having to > know that it was a MMU-600 at all. Using SOC_ID means that going forward, userspace needs to learn about the integration details of each SoC in order to identify a component. As you said: | As constantly checking what the SoC ID means throughout system components | does not scale. ... and I think that equally applies to userspace in this case. Who knows how many SoCs are going to have MMU-600? I also know that SOC_ID is going to be optional, and I think it's near-certain that someone will end up producing two SoCs exposing the same ID. For system PMUs, I'd rather the system PMU driver exposed some sort of implementation ID. e.g. the SMMU_ID for SMMU. We can give that a generic name, and mandate that where a driver exposes it, the format/meaning is defined in the documentation for the driver. That can be namespace by driver, so e.g. keys would be smmu_sysfs_name/ and ddrc_sysfs_name/. > > > So even if it is solvable here, the kernel driver(s) will need to be > > > reworked. And that is just solving one case in many. > > > > PMU drivers will need to expose more information to userspace so that they > > can be identified more precisely, yes. I wouldn't say they would need to be > > "reworked". > > OK, so some combination of changes would still be required for the SMMU > PMCG, IORT, and SMMUv3 drivers. To expose the SMMU ID, surely that's just the driver? Or are there implementations where the ID register is bogus and have to be overridden? Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel