From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FE77288C08 for ; Tue, 9 Dec 2025 11:31:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765279915; cv=none; b=BPfCGLf+Eqtub5QvQROtb+qcCsiTaQfHVZeAvSaNt1yu+yGZyeF4KZlgO6A02xOH6wwexakR5h4AxFffcKz6SD7Hq/eW5u2HQyLjNEf8J0CS1BZPDOXIsz/fisdZ3XcXJVrxpwcQDrhhYFnDDbSbCr0UHGjuREEGWLDEr6HEULs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765279915; c=relaxed/simple; bh=6HH/cxAGt3ABS3t90IUPQ0e68wSNZs8U8QlS2Iiv/WY=; h=Message-ID:Date:MIME-Version:Subject:To:References:Cc:From: In-Reply-To:Content-Type; b=rp2UQITSfdS4LdWVIxg4P6BnhLCztZPwDVUOWEZUivhEJCXaNUE3SBUGrRCH/T0pR91xvJjhockuDOY21L59ZnH8f3gi3tkxBZ8/1OTJWLorRFbB1Fa/tyu/Ekmtbh3X2fD9qVFGbLoA8Y++lCqs65BPlCxMLUlxDSjOIRoWDYU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=DT1i7a2e; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="DT1i7a2e" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-42e33956e76so2489256f8f.3 for ; Tue, 09 Dec 2025 03:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1765279912; x=1765884712; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=e6YWuMvXTNdTJOhHcDzcUXEKOmVYtdsSHdCKcDTVbug=; b=DT1i7a2eRvbRFikyVj47zjez4/UWBN1J7kivgWUWjlq3Sv6tjR54FeDoMTGhctz3yM S+d+cNT8fIhjS5g5vvYzA20G4htXtX4qlu/+axDox2CQeQh2CxLfS7Jzzdauot1J3zF9 aURA3nJFC7Qoo23046Q9T9G4VYlI1s5TtJ0L8S5TPkpi0pTELk6cVR9CDRPeEoszb8km jn0IStgPmKYSEhEhK6SGBphx2uh+ZsexeJtmmXMxkioLf6FP/MmX2b7XGnzJuSVIqQcu Z2siNOzr7ObaEpHrcEIn6fIj0ln4ysZc/G5iEvHlZLnLD9ociQP6q35+qBjeb+i5mpnb BB0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765279912; x=1765884712; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=e6YWuMvXTNdTJOhHcDzcUXEKOmVYtdsSHdCKcDTVbug=; b=Z7HFNPSXxd5271VUXkob5Jhrm5v30BNwF4o0vgtbH9UC1EJRwvyjMcgCbhUGxF2Sxu KQqs6/iAA+nzwHPGvDPcU87xmTAbDnhwFKYF+rd1pLKBGrvJYn0JYjgLk+/yTU0Qj3wq fnY61v2Pih2FzOm+YbFNgN92O/4l8P23tAqWVGhmZDxK433dIZnygTkLTgH9q8KScQ65 px4jg0b9Q+W8vrxiEKfY7Q8YKUm33G/3SXOQ/+CkBVTkeCtsfqpiO5Wj8tgk3eoERqLc izhObeYbhb+zd+j9rDY8Zy4+CyGyEfOv0xLtOQOQifQV7EfAx2rZDROsny1i3N64CQw3 fNKg== X-Forwarded-Encrypted: i=1; AJvYcCVRTAJ/Al9xd6b1vyobS8kvPKznMZBAnX1I4E3cBvTMexZDP1vmbF5ilQ7uSIZrwOj6htpkRjRwEH2+Xco=@vger.kernel.org X-Gm-Message-State: AOJu0YxT0t00xkanC49VuKzweKp9V0XUncbuSPT1G/6WtPAfDjSKNA29 4hRujYh13yoB5NfQXARtQ06w3gbRODWkCZC3PSOqXnSDJnmyVmdVzOgelrxj0n/nWS8= X-Gm-Gg: ASbGncsGjTYD+D55u9EqoqFJ7pWicU9iJF/yU46G7dRJFwvUwyRxhE1qUr2uXSOQ62O uMQIjFydgZumwHDXbRhrGxDiflLLx94/u7rt0VF+Nk5eDjw3AxKuToEaUvLTIjNL/FTbp94NeuA oaDr88+QE2dl9z5qVJU5RA2j5Gri2VfiSCPBVz/8PmqlNGTT6of1b37aelSSCAqkYkZFGCSNbDK 41QNwhmMCo9bv52IUggIIuewZvAfbs/nGPY3ZdeDm4fiGUcPY67Ghh4YwzXgew3yZ2FbpjVZoXh 5Jb3Tv2Kt5um9hZsUCpfKv183E1xPFwAUm05XqfRWsXR9LH6cogaiDhg5N7N3H2/RUklPZCc1sb CnguS+S6ic63o5fG27U83DWjkHMC66R1lC3B5SVktBjUw102O/xukT91M0LdZMHrsYOE8bgBlN3 lIxp9ptb11kXNNtx+d X-Google-Smtp-Source: AGHT+IEwfVpq4vEyyu/zMlGG00IRvDaLPlzEHvJE6y+B8GWLHwhzhlMF/Zpeb50z/1x4UmBzouJKYg== X-Received: by 2002:a05:6000:4301:b0:429:8d0f:e92 with SMTP id ffacd0b85a97d-42f89f0abbemr10139233f8f.6.1765279911677; Tue, 09 Dec 2025 03:31:51 -0800 (PST) Received: from [192.168.1.3] ([185.48.77.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7cbff320sm31190157f8f.18.2025.12.09.03.31.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Dec 2025 03:31:51 -0800 (PST) Message-ID: Date: Tue, 9 Dec 2025 11:31:49 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 46/48] perf jevents: Add collection of topdown like metrics for arm64 To: Ian Rogers , Andi Kleen , "Liang, Kan" References: <20251202175043.623597-1-irogers@google.com> <20251202175043.623597-47-irogers@google.com> Content-Language: en-US Cc: Adrian Hunter , Alexander Shishkin , Arnaldo Carvalho de Melo , Benjamin Gray , Caleb Biggers , Edward Baker , Ingo Molnar , Jing Zhang , Jiri Olsa , John Garry , Leo Yan , Namhyung Kim , Perry Taylor , Peter Zijlstra , Samantha Alt , Sandipan Das , Thomas Falcon , Weilin Wang , Xu Yang , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org From: James Clark In-Reply-To: <20251202175043.623597-47-irogers@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/12/2025 5:50 pm, Ian Rogers wrote: > Metrics are created using legacy, common and recommended events. As > events may be missing a TryEvent function will give None if an event > is missing. To workaround missing JSON events for cortex-a53, sysfs > encodings are used. > > Signed-off-by: Ian Rogers > --- > An earlier review of this patch by Leo Yan is here: > https://lore.kernel.org/lkml/8168c713-005c-4fd9-a928-66763dab746a@arm.com/ > Hopefully all corrections were made. > --- > tools/perf/pmu-events/arm64_metrics.py | 145 ++++++++++++++++++++++++- > 1 file changed, 142 insertions(+), 3 deletions(-) > [...] > + MetricGroup("lpm_topdown_be_bound", [ > + MetricGroup("lpm_topdown_be_dtlb", [ > + Metric("lpm_topdown_be_dtlb_walks", "Dtlb walks per instruction", > + d_ratio(dtlb_walk, ins_ret), "walk/insn"), > + Metric("lpm_topdown_be_dtlb_walk_rate", "Dtlb walks per L1D TLB access", > + d_ratio(dtlb_walk, l1d_tlb) if l1d_tlb else None, "100%"), > + ]) if dtlb_walk else None, > + MetricGroup("lpm_topdown_be_mix", [ > + Metric("lpm_topdown_be_mix_ld", "Percentage of load instructions", > + d_ratio(ld_spec, inst_spec), "100%") if ld_spec else None, > + Metric("lpm_topdown_be_mix_st", "Percentage of store instructions", > + d_ratio(st_spec, inst_spec), "100%") if st_spec else None, > + Metric("lpm_topdown_be_mix_simd", "Percentage of SIMD instructions", > + d_ratio(ase_spec, inst_spec), "100%") if ase_spec else None, > + Metric("lpm_topdown_be_mix_fp", > + "Percentage of floating point instructions", > + d_ratio(vfp_spec, inst_spec), "100%") if vfp_spec else None, > + Metric("lpm_topdown_be_mix_dp", > + "Percentage of data processing instructions", > + d_ratio(dp_spec, inst_spec), "100%") if dp_spec else None, > + Metric("lpm_topdown_be_mix_crypto", > + "Percentage of data processing instructions", > + d_ratio(crypto_spec, inst_spec), "100%") if crypto_spec else None, > + Metric( > + "lpm_topdown_be_mix_br", "Percentage of branch instructions", > + d_ratio(br_immed_spec + br_indirect_spec + br_ret_spec, > + inst_spec), "100%") if br_immed_spec and br_indirect_spec and br_ret_spec else None, Hi Ian, I've been trying to engage with the team that's publishing the metrics in Arm [1] to see if there was any chance in getting some unity between these new metrics and their existing json ones. The feedback from them was that the decision to only publish metrics for certain cores is deliberate and there is no plan to change anything. The metrics there are well tested, known to be working, and usually contain workarounds for specific issues. They don't want to do "Arm wide" common metrics for existing cores as they believe it has more potential to mislead people than help. I'm commenting on this "lpm_topdown_be_mix_br" as one example, that the equivalent Arm metric "branch_percentage" excludes br_ret_spec because br_indirect_spec also counts returns. Or on neoverse-n3 it's "PC_WRITE_SPEC / INST_SPEC". I see that you've prefixed all the metrics so the names won't clash from Kan's feedback [2]. But it makes me wonder if at some point some kind of alias list could be implemented to override the generated metrics with hand written json ones. But by that point why not just use the same names? The Arm metric team's feedback was that there isn't really an industry standard for naming, and that differences between architectures would make it almost impossible to standardise anyway in their opinion. But here we're adding duplicate metrics with different names, where the new ones are known to have issues. It's not a great user experience IMO, but at the same time missing old cores from the Arm metrics isn't a great user experience either. I actually don't have a solution, other than to say I tried to get them to consider more unified naming. I also have to say that I do still agree with Andi's old feedback [3] that the existing json was good enough, and maybe this isn't the right direction, although it's not very useful feedback at this point. I thought I had replied to that thread long ago, but must not have pressed send, sorry about that. [1]: https://gitlab.arm.com/telemetry-solution/telemetry-solution/-/tree/main/data [2]: https://lore.kernel.org/lkml/43548903-b7c8-47c4-b1da-0258293ecbd4@linux.intel.com [3]: https://lore.kernel.org/lkml/ZeJJyCmXO9GxpDiF@tassilo/