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 3A0E4C433FE for ; Mon, 16 May 2022 11:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242917AbiEPLKg (ORCPT ); Mon, 16 May 2022 07:10:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231337AbiEPLKb (ORCPT ); Mon, 16 May 2022 07:10:31 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05E412F004; Mon, 16 May 2022 04:10:29 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4L1xK23xzzz6GCX1; Mon, 16 May 2022 19:06:46 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 16 May 2022 13:10:26 +0200 Received: from [10.47.25.151] (10.47.25.151) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 16 May 2022 12:10:25 +0100 Message-ID: Date: Mon, 16 May 2022 12:10:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs To: Ian Rogers CC: Nick Forrington , , , 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 , Arnaldo Carvalho de Melo , Qi Liu References: <20220510104758.64677-1-nick.forrington@arm.com> <1062b28d-9c7b-89fb-d3bf-519f84029b96@huawei.com> From: John Garry In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.25.151] X-ClientProxiedBy: lhreml714-chm.china.huawei.com (10.201.108.65) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/05/2022 23:03, Ian Rogers wrote: > I'll raise John's "ok" and say this looks great!:-D Some thoughts: > > The mapfile.csv cpuid values don't directly align with: > https://github.com/ARM-software/data/blob/master/cpus.json > but this definitely looks deliberate. > Hi Ian, > The new events lack the PMU "Unit" value. For arm support we work on the basis that no "Unit" means CPU PMU. I assume the same for other archs, but maybe this hybrid PMU support changes that. > The current perf json is > pretty free form and leads to problems if two PMUs are present. Can you clarify - for my benefit - exactly what you mean by "two PMUs are present"? > Context is here: > https://lore.kernel.org/lkml/CAP-5=fWRRZsyJZ-gky-FOFz79zW_3r78d_0APpj5sf66HqTpLw@mail.gmail.com/ > We have another problem but I am not sure if exactly the same. The issue is that if we have an event alias "cycles" for an uncore PMU, then if we use "stat" command then perf tool matches "cycles" to CPU cycles and not the uncore PMU, which we would not want. We have ways to work around it, though. > My idea to rationalize this is to mirror what is already done in > sysfs, that is the event data is specific to a PMU. As a lot of "Unit" > values are missing from events on x86 a reasonable guess if the "Unit" > is missing is to use "cpu". This sounds like what I mentioned in the reply to 1/20: "I had a patch series which makes perf read the armv8 pmu sysfs event file to learn all the events which the core supports and create the aliases from that. So, in this, we don't require the JSONs to list these events explicitly. " Is this like what Andi was talking about in terms of runtime loading? > Poking a Google Pixel 4a, I see that all > PMU data is in "armv8_pmuv3". So for ARM I could guess this is always > the case, ie all events should belong to armv8_pmuv3. This may not be > right and could lead to confusion like an event BR_COND_MIS_PRED > having an alias of "armv8_pmuv3/BR_COND_MIS_PRED/" but it really > should have some other PMU name in there. I just raise this in case > there is a fix for this we could incorporate into this patch series, > maybe "armv8_pmuv3" is always the PMU and my life is easy. Thanks, John