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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C78FFC433F5 for ; Wed, 18 May 2022 14:14:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238549AbiEROOi (ORCPT ); Wed, 18 May 2022 10:14:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238524AbiEROOh (ORCPT ); Wed, 18 May 2022 10:14:37 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D053C1C9AF6; Wed, 18 May 2022 07:14:35 -0700 (PDT) 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 8BC5B23A; Wed, 18 May 2022 07:14:35 -0700 (PDT) Received: from [10.57.82.55] (unknown [10.57.82.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AC9843F73D; Wed, 18 May 2022 07:14:32 -0700 (PDT) Message-ID: <7a17256d-cad0-bd94-02e7-f8adaa959654@arm.com> Date: Wed, 18 May 2022 15:14:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs Content-Language: en-GB To: John Garry , Nick Forrington , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, acme@kernel.org Cc: Will Deacon , Mathieu Poirier , Leo Yan , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Andi Kleen , Kajol Jain , James Clark , Andrew Kilroy References: <20220510104758.64677-1-nick.forrington@arm.com> <28509191-3a45-de6d-f5bc-a8e7331c0a9e@huawei.com> <5773b630-8159-1eba-481a-1bf3c406c055@arm.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-05-18 14:48, John Garry wrote: > On 18/05/2022 13:32, Robin Murphy wrote: >>> If we were to add to arm32/arm then the common event numbers and >>> maybe other JSONs in future would need to be duplicated. >>> >>> Would there be any reason to add to arm32/arm apart to from being >>> strictly proper? Maybe if lots of other 32b support for other vendors >>> came along then it could make sense (to separate them out). >> >> That's the heart of the question, really. At best it seems >> unnecessarily confusing as-is. > > I think it comes down to the first core supported was TX2 and the build > system relies on the target arch to decide which arch from > pmu-events/arch to compile. > >> AFAICS either the naming isn't functional, wherein it would >> potentially make the most sense to rename the whole thing >> "pmu-events/arch/arm" if it's merely for categorising Arm >> architectures in general, or it is actually tied to the host triplet, >> in which case the above patches are most likely useless. > > Today ARCH=arm has no pmu-events support. I think that it should be easy > to add plumbing for that. It becomes more tricky with supporting a > single "arm" folder. > > But then do people really care enough about pmu-events for these 32b > cores? Until now, it seems not. > >> >> I'd agree that there doesn't seem much point in trying to separate >> things along relatively arbitrary lines if it *isn't* functionally >> necessary - the PMUv2 common events look to be a straightforward >> subset of the PMUv3 ones, but then there's Cortex-A32 anyway, plus >> most of the already-supported CPUs could equally run an AArch32 perf >> tool as well. > > Sure, we should have these 32b cores supported for ARCH=arm if they are > supported for ARCH=arm64. But then does it even make sense to have A7 > support in arch/arm64? That's what I'm getting at. If it is tied to the build target as you've said above, then there is no point in an AArch64 perf tool including data for CPUs on which that tool cannot possibly run; it's simply a waste of space. If there is interest in plumbing in support on AArch32 builds as well, then I'd still be inclined to have a single arch/arm events directory, and either do some build-time path munging or just symlink an arch/arm64 sibling back to it. Yes, technically there are AArch64-only CPUs whose data would then be redundant when building for AArch32, but those are such a minority that it seems like an entirely reasonable compromise. Thanks, Robin.