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 12DAEC433F5 for ; Wed, 5 Jan 2022 06:14:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236392AbiAEGOH (ORCPT ); Wed, 5 Jan 2022 01:14:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236391AbiAEGOF (ORCPT ); Wed, 5 Jan 2022 01:14:05 -0500 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7621DC061784 for ; Tue, 4 Jan 2022 22:14:05 -0800 (PST) Received: by mail-yb1-xb4a.google.com with SMTP id s83-20020a255e56000000b0060c46cc1890so50231351ybb.16 for ; Tue, 04 Jan 2022 22:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=HQ0F4Wkpc2hZGLs9o4VVEd71gbRETuZn+IEXms79S7Y=; b=e7KHiU59v84EyoMHS5p2Mg5EgcEElA1lH8I4u/X+iDw3Pg+SJIKMO7PGa6gZEyh1XI jcYslOJImrqtnUkMdgokHbevuybXcRdcxcF3cJqQM5xjp7JBini9Ss6qlpKVJgpcy8aK kcYpSIrLu8/S9UJpTlNF4Bmh8jV+zB9mOC3X/HUbKBhodtWYfOFJsMtzh/b6Jj5+kqbi f+PtIdaIKIaOZL+x0dA2kDiOSHXTiD5zwMkbkbjTfIfkkY5+De17jv8GXZVHiGf71IYj Y15Yob7D7V6e8tHxQ90O3dH72V3YP7XLiy2iuIUyC8C25WWTijmA1FBnXEEs1aOQXEe7 fM6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=HQ0F4Wkpc2hZGLs9o4VVEd71gbRETuZn+IEXms79S7Y=; b=BpkEr85pZh7SB8w0L4Y8Gjn9yOf3s9uavvd2ByVdQA8PzaOPFGMxSHmCibp2bfBMQX kG/8q0S6hGP3jnNpUIV0I6wptFB2fYHustnzJtk84PG8fFf7dj4cccw6OtcdKF9lemxn 77JlybGdBhjpArHf1UDoSfQxzP3OYCDtAxMfw+so/1sadbXbYcFCZKWtYF0RZAomOvOg zQXJS7NsDVOTBEZdocLTviGFxGZuKJl2gIgXniZfAnJzNgXVvGClxTXnM0Lovz6kbIOT Z8MGUnNBvSpQT67DZ091jXCgFj4tOYG50cc7duM/MdzZVxYzexGlIKr827EZ6d/JmI7h vC6w== X-Gm-Message-State: AOAM532IjZOe6I6JnL/Miu91ECQCRQibxo3FkSdDEKvVz0QL5g1vZRJP ynfrOJkxW4Q1WBhp7ea99wfRAKKg5rK7 X-Google-Smtp-Source: ABdhPJz9nken52ZH9X0zSHsdDA6FM1TTMIEc4BBm/a+cJg95yA6r1/pwxo5E8ciy7XOc+W2WF5GEtPb45iDP X-Received: from irogers.svl.corp.google.com ([2620:15c:2cd:202:3af1:caef:2937:5d2b]) (user=irogers job=sendgmr) by 2002:a25:d2d8:: with SMTP id j207mr53245977ybg.699.1641363244715; Tue, 04 Jan 2022 22:14:04 -0800 (PST) Date: Tue, 4 Jan 2022 22:13:06 -0800 In-Reply-To: <20220105061351.120843-1-irogers@google.com> Message-Id: <20220105061351.120843-4-irogers@google.com> Mime-Version: 1.0 References: <20220105061351.120843-1-irogers@google.com> X-Mailer: git-send-email 2.34.1.448.ga2b2bfdf31-goog Subject: [PATCH v4 03/48] perf stat: Correct aggregation CPU map From: Ian Rogers To: Andi Kleen , Jiri Olsa , Namhyung Kim , John Garry , Kajol Jain , "Paul A . Clarke" , Arnaldo Carvalho de Melo , Riccardo Mancini , Kan Liang , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Vineet Singh , James Clark , Mathieu Poirier , Suzuki K Poulose , Mike Leach , Leo Yan , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, zhengjun.xing@intel.com Cc: eranian@google.com, Ian Rogers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org Switch the perf_cpu_map in aggr_update_shadow from the evlist to the counter's cpu map, so the index is appropriate. This addresses a problem where uncore counts, with a cpumap like: $ cat /sys/devices/uncore_imc_0/cpumask 0,18 Don't aggregate counts in CPUs based on the index of those values in the cpumap (0 and 1) but on the actual CPU (0 and 18). Thereby correcting metric calculations in per-socket mode for counters without a full cpumask. On a SkylakeX with a tweaked DRAM_BW_Use metric, to remove unnecessary scaling, this gives: Before: $ /perf stat --per-socket -M DRAM_BW_Use -I 1000 1.001102293 S0 1 27.01 MiB uncore_imc/cas_count_write/ # 103.00 DRAM_BW_Use 1.001102293 S0 1 30.22 MiB uncore_imc/cas_count_read/ 1.001102293 S0 1 1,001,102,293 ns duration_time 1.001102293 S1 1 20.10 MiB uncore_imc/cas_count_write/ # 0.00 DRAM_BW_Use 1.001102293 S1 1 32.74 MiB uncore_imc/cas_count_read/ 1.001102293 S1 0 ns duration_time 2.003517973 S0 1 83.04 MiB uncore_imc/cas_count_write/ # 920.00 DRAM_BW_Use 2.003517973 S0 1 145.95 MiB uncore_imc/cas_count_read/ 2.003517973 S0 1 1,002,415,680 ns duration_time 2.003517973 S1 1 302.45 MiB uncore_imc/cas_count_write/ # 0.00 DRAM_BW_Use 2.003517973 S1 1 290.99 MiB uncore_imc/cas_count_read/ 2.003517973 S1 0 ns duration_time After: $ perf stat --per-socket -M DRAM_BW_Use -I 1000 1.001080840 S0 1 24.96 MiB uncore_imc/cas_count_write/ # 54.00 DRAM_BW_Use 1.001080840 S0 1 33.64 MiB uncore_imc/cas_count_read/ 1.001080840 S0 1 1,001,080,840 ns duration_time 1.001080840 S1 1 42.43 MiB uncore_imc/cas_count_write/ # 84.00 DRAM_BW_Use 1.001080840 S1 1 47.05 MiB uncore_imc/cas_count_read/ 1.001080840 S1 0 ns duration_time Signed-off-by: Ian Rogers --- tools/perf/util/stat-display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c index 588601000f3f..b0fa81ffce61 100644 --- a/tools/perf/util/stat-display.c +++ b/tools/perf/util/stat-display.c @@ -526,7 +526,7 @@ static void aggr_update_shadow(struct perf_stat_config *config, evlist__for_each_entry(evlist, counter) { val = 0; for (cpu = 0; cpu < evsel__nr_cpus(counter); cpu++) { - s2 = config->aggr_get_id(config, evlist->core.cpus, cpu); + s2 = config->aggr_get_id(config, evsel__cpus(counter), cpu); if (!cpu_map__compare_aggr_cpu_id(s2, id)) continue; val += perf_counts(counter->counts, cpu, 0)->val; -- 2.34.1.448.ga2b2bfdf31-goog