Message ID | 20230302212531.1043318-3-irogers@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp101679wrd; Thu, 2 Mar 2023 14:31:25 -0800 (PST) X-Google-Smtp-Source: AK7set/S/dttN5BH/3q9vSVMajShCQOWrAS2HAzZDulZGNOXjZnMgsRYpFDYegUTWFsjH3Rs24JP X-Received: by 2002:a17:906:81c8:b0:8de:baf0:3384 with SMTP id e8-20020a17090681c800b008debaf03384mr11975480ejx.77.1677796285494; Thu, 02 Mar 2023 14:31:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677796285; cv=none; d=google.com; s=arc-20160816; b=DgQVpKzAlek5H9HUQkVNE4VuiZKluDiPl/w6eLQr8ti9jvDxZKJz32PipDKc7ayXe3 KLYPnUFtWB0QHEdxTI9RYm0HEd4Eg7cVtDfNztUawNH4Je8PSZzYHhX88qcmp1r13wtF T0o2AvlhQP0QwhWXo4elAwgFjsKM53AVmCLw5IbAR/PRS/XKK5CE2/vLvtQCk2GXnTeo VYd60i3557YkYcNAmZMNtRRyEbbSKXS0j3m+HyclmvHo4Eoc89NPrUEs3JbLJL8cjtLi a1NLjXbn6KHI/BqJs+d6rbV3H7sYYDgctgBphOnxdmBMAtUDxENHmyVnf6EPfvsPuVm6 o+GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:dkim-signature; bh=dvqLbFbIa5Th4hLVJzIhGZ3VgrtC26zZgF3M8vwaoio=; b=t3kZqj4YG0wgyHDW8L6INiVpP1SiLdpEqUF4y+Xu1IbPz3aChYwgEPU+wqfDb7cSPA eiNbU/1/dzepPkC2XACWHWelqmT8bSboJCBbJx5qdwYQujkWcFjTs8V8ZZLqiMbVb3Gy LD3VK3papzHVULhFeNio/JX/9AsLUL1p3X0EjplJ8ci+gR+a723dF6R1T74dyz5oP0ZL RoWaBOwM4oxCtPG12GPumMs6jH6w70ZmnkGRUHPuaf4hKMUniHnV074dcBC5rRPz7SxN LztGTioSaHH+gKQ5LzvGqkCuX+VIAV/8Wx9s3I03jInJN9uuDrwoxOrSFuF9jg3Hl/y5 UDzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=rZijt3Yx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c17-20020a170906d19100b008d3be841ccdsi444602ejz.326.2023.03.02.14.31.02; Thu, 02 Mar 2023 14:31:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=rZijt3Yx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230025AbjCBWZu (ORCPT <rfc822;davidbtadokoro@gmail.com> + 99 others); Thu, 2 Mar 2023 17:25:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230020AbjCBWZs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Mar 2023 17:25:48 -0500 Received: from mail-oi1-x24a.google.com (mail-oi1-x24a.google.com [IPv6:2607:f8b0:4864:20::24a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 029351EBDC for <linux-kernel@vger.kernel.org>; Thu, 2 Mar 2023 14:25:48 -0800 (PST) Received: by mail-oi1-x24a.google.com with SMTP id cb5-20020a056808320500b003848c5da32eso234569oib.7 for <linux-kernel@vger.kernel.org>; Thu, 02 Mar 2023 14:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677795947; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=dvqLbFbIa5Th4hLVJzIhGZ3VgrtC26zZgF3M8vwaoio=; b=rZijt3Yx2sv0qazNjKmSENaCWQCuL6oHZlInKQisJCAXXyB9MBoew7x24yXzFFX6/X fOLNPR4rafmVmS+2FYLhTMIhHiTK9tMZxKx4IjI17mq3VGV2WVOPSSUfLrz9pnPkW+Qn Xr/kUsibWvHj+pNRYUfqNCxhO92tr3UsOpw0C/Kv7PZmUAQP0i0u46TEbAqOV1yUTxzn Ic77SNqoY80nyCHMoi3tJ8OnegCAC8EoqIjm5lRLDoaiB8+Y0/Ea63LNEq3YIsOB47Jh T1wLvaqXTYe+Vw5nX+4KBclL42tHjdUkRVx1gf43glaD62/ZwQ+XHxoFKD6FdQRCan2f jrNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677795947; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dvqLbFbIa5Th4hLVJzIhGZ3VgrtC26zZgF3M8vwaoio=; b=l+AF4ifHLqyXoH5cdimwV4d8p7zuf6PGi9ZOuA/juXs9TUt4W9qnD62o+vog/H9f8b PqydA1LMlyxrdZYnXYPHjZxm2XVifYblqbtk5yaF1EBicrNe/GflQitamHzXZR/cBuj2 V1menqs3OiZCEuDfy0mT6zRkYZk2OB3V4KEccLtGXORnwfCQkT1TKmInEihsIEICAsIv 2wZL17AVwtIjlZJ8Q0VvAHYYz9lqIZBkJLjI9F3ycEkleo9lZxOEMI1BmIAHQx0+Fn3T ZlAkgHIcmnkt8etoRrKoE4FawVSFzmZLWYhG/CZUi1gbtoBCBWiVonkYF1bzJzHpGEDV NuDw== X-Gm-Message-State: AO0yUKXhud3wgzSRZDHq4UfJmEE7h8tIBNM5vS5ml+adO0Qwrk5+P3te P0qg+ogv1aScfKzSWqokxebXx14HVkI1 X-Received: from irogers.svl.corp.google.com ([2620:15c:2d4:203:5f50:6ef4:b4d0:568e]) (user=irogers job=sendgmr) by 2002:a05:6902:101:b0:a4e:4575:f3ec with SMTP id o1-20020a056902010100b00a4e4575f3ecmr5273607ybh.0.1677792363948; Thu, 02 Mar 2023 13:26:03 -0800 (PST) Date: Thu, 2 Mar 2023 13:25:23 -0800 In-Reply-To: <20230302212531.1043318-1-irogers@google.com> Message-Id: <20230302212531.1043318-3-irogers@google.com> Mime-Version: 1.0 References: <20230302212531.1043318-1-irogers@google.com> X-Mailer: git-send-email 2.40.0.rc0.216.gc4246ad0f0-goog Subject: [PATCH v2 02/10] perf stat: Don't remove all grouped events when CPU maps disagree From: Ian Rogers <irogers@google.com> To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Kan Liang <kan.liang@linux.intel.com>, Zhengjun Xing <zhengjun.xing@linux.intel.com>, Ravi Bangoria <ravi.bangoria@amd.com>, Adrian Hunter <adrian.hunter@intel.com>, "Steinar H. Gunderson" <sesse@google.com>, Kim Phillips <kim.phillips@amd.com>, Florian Fischer <florian.fischer@muhq.space>, James Clark <james.clark@arm.com>, Suzuki Poulouse <suzuki.poulose@arm.com>, Sean Christopherson <seanjc@google.com>, Leo Yan <leo.yan@linaro.org>, John Garry <john.g.garry@oracle.com>, Kajol Jain <kjain@linux.ibm.com>, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Stephane Eranian <eranian@google.com>, Ian Rogers <irogers@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759296917822906921?= X-GMAIL-MSGID: =?utf-8?q?1759296917822906921?= |
Series |
Better fixes for grouping of events
|
|
Commit Message
Ian Rogers
March 2, 2023, 9:25 p.m. UTC
If the events in an evlist's CPU map differ then the entire group is
removed. For example:
```
$ perf stat -e '{imc_free_running/data_read/,imc_free_running/data_write/,cs}' -a sleep 1
WARNING: grouped events cpus do not match, disabling group:
anon group { imc_free_running/data_read/, imc_free_running/data_write/, cs }
```
Change the behavior so that just the events not matching the leader
are removed. So in the example above, just 'cs' will be removed.
Modify the warning so that it is produced once for each group, rather
than once for the entire evlist. Shrink the scope and size of the
warning text buffer.
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/perf/builtin-stat.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
Comments
On 2023-03-02 4:25 p.m., Ian Rogers wrote: > If the events in an evlist's CPU map differ then the entire group is > removed. For example: > > ``` > $ perf stat -e '{imc_free_running/data_read/,imc_free_running/data_write/,cs}' -a sleep 1 > WARNING: grouped events cpus do not match, disabling group: > anon group { imc_free_running/data_read/, imc_free_running/data_write/, cs } > ``` > > Change the behavior so that just the events not matching the leader > are removed. So in the example above, just 'cs' will be removed. > > Modify the warning so that it is produced once for each group, rather > than once for the entire evlist. Shrink the scope and size of the > warning text buffer. For the uncore, we usually have to create a group for each uncore PMU. The number of groups may be big. For example, on ICX, we have 40 CHA PMUs. For SPR, there should be more CHAs. If we have something like {cycles,uncore_cha/event=0x1/}, is the warning shown 40 times on ICX? If so, it should be very annoying. Maybe it's better to keep the current behavior which only print a warning once and notify the users that perf will re-group the events. For the details, they can get it from the -v option. Thanks, Kan > > Signed-off-by: Ian Rogers <irogers@google.com> > --- > tools/perf/builtin-stat.c | 24 +++++++++++++++--------- > 1 file changed, 15 insertions(+), 9 deletions(-) > > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c > index d70b1ec88594..5c12ae5efce5 100644 > --- a/tools/perf/builtin-stat.c > +++ b/tools/perf/builtin-stat.c > @@ -181,14 +181,13 @@ static bool cpus_map_matched(struct evsel *a, struct evsel *b) > > static void evlist__check_cpu_maps(struct evlist *evlist) > { > - struct evsel *evsel, *pos, *leader; > - char buf[1024]; > + struct evsel *evsel, *warned_leader = NULL; > > if (evlist__has_hybrid(evlist)) > evlist__warn_hybrid_group(evlist); > > evlist__for_each_entry(evlist, evsel) { > - leader = evsel__leader(evsel); > + struct evsel *leader = evsel__leader(evsel); > > /* Check that leader matches cpus with each member. */ > if (leader == evsel) > @@ -197,19 +196,26 @@ static void evlist__check_cpu_maps(struct evlist *evlist) > continue; > > /* If there's mismatch disable the group and warn user. */ > - WARN_ONCE(1, "WARNING: grouped events cpus do not match, disabling group:\n"); > - evsel__group_desc(leader, buf, sizeof(buf)); > - pr_warning(" %s\n", buf); > - > + if (warned_leader != leader) { > + char buf[200]; > + > + pr_warning("WARNING: grouped events cpus do not match.\n" > + "Events with CPUs not matching the leader will " > + "be removed from the group.\n"); > + evsel__group_desc(leader, buf, sizeof(buf)); > + pr_warning(" %s\n", buf); > + warned_leader = leader; > + } > if (verbose > 0) { > + char buf[200]; > + > cpu_map__snprint(leader->core.cpus, buf, sizeof(buf)); > pr_warning(" %s: %s\n", leader->name, buf); > cpu_map__snprint(evsel->core.cpus, buf, sizeof(buf)); > pr_warning(" %s: %s\n", evsel->name, buf); > } > > - for_each_group_evsel(pos, leader) > - evsel__remove_from_group(pos, leader); > + evsel__remove_from_group(evsel, leader); > } > } >
On Fri, Mar 3, 2023 at 7:50 AM Liang, Kan <kan.liang@linux.intel.com> wrote: > > > > On 2023-03-02 4:25 p.m., Ian Rogers wrote: > > If the events in an evlist's CPU map differ then the entire group is > > removed. For example: > > > > ``` > > $ perf stat -e '{imc_free_running/data_read/,imc_free_running/data_write/,cs}' -a sleep 1 > > WARNING: grouped events cpus do not match, disabling group: > > anon group { imc_free_running/data_read/, imc_free_running/data_write/, cs } > > ``` > > > > Change the behavior so that just the events not matching the leader > > are removed. So in the example above, just 'cs' will be removed. > > > > Modify the warning so that it is produced once for each group, rather > > than once for the entire evlist. Shrink the scope and size of the > > warning text buffer. > > For the uncore, we usually have to create a group for each uncore PMU. > The number of groups may be big. For example, on ICX, we have 40 CHA > PMUs. For SPR, there should be more CHAs. If we have something like > {cycles,uncore_cha/event=0x1/}, is the warning shown 40 times on ICX? > If so, it should be very annoying. > > Maybe it's better to keep the current behavior which only print a > warning once and notify the users that perf will re-group the events. > For the details, they can get it from the -v option. Thanks Kan, I could imagine that but I was also worried about cases where there are multiple groups like: ``` $ perf stat -e '{imc_free_running/data_read/,cs},{uncore_clock/clockticks/,cs}' -a sleep 1 WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { imc_free_running/data_read/, cs } WARNING: grouped events cpus do not match. Events with CPUs not matching the leader will be removed from the group. anon group { uncore_clock/clockticks/, cs } Performance counter stats for 'system wide': 1,255.75 MiB imc_free_running/data_read/ 7,571 cs 1,327,285,527 uncore_clock/clockticks/ 7,571 cs 1.002772882 seconds time elapsed ``` Knowing that both groups were broken there feels like a value add. Given that this is a warning, and it can be fixed by moving the event out of the group or forcing the CPUs, I lean toward being informative/spammy as the spam is somewhat straightforwardly fixed on the command line. Thanks, Ian > Thanks, > Kan > > > > Signed-off-by: Ian Rogers <irogers@google.com> > > --- > > tools/perf/builtin-stat.c | 24 +++++++++++++++--------- > > 1 file changed, 15 insertions(+), 9 deletions(-) > > > > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c > > index d70b1ec88594..5c12ae5efce5 100644 > > --- a/tools/perf/builtin-stat.c > > +++ b/tools/perf/builtin-stat.c > > @@ -181,14 +181,13 @@ static bool cpus_map_matched(struct evsel *a, struct evsel *b) > > > > static void evlist__check_cpu_maps(struct evlist *evlist) > > { > > - struct evsel *evsel, *pos, *leader; > > - char buf[1024]; > > + struct evsel *evsel, *warned_leader = NULL; > > > > if (evlist__has_hybrid(evlist)) > > evlist__warn_hybrid_group(evlist); > > > > evlist__for_each_entry(evlist, evsel) { > > - leader = evsel__leader(evsel); > > + struct evsel *leader = evsel__leader(evsel); > > > > /* Check that leader matches cpus with each member. */ > > if (leader == evsel) > > @@ -197,19 +196,26 @@ static void evlist__check_cpu_maps(struct evlist *evlist) > > continue; > > > > /* If there's mismatch disable the group and warn user. */ > > - WARN_ONCE(1, "WARNING: grouped events cpus do not match, disabling group:\n"); > > - evsel__group_desc(leader, buf, sizeof(buf)); > > - pr_warning(" %s\n", buf); > > - > > + if (warned_leader != leader) { > > + char buf[200]; > > + > > + pr_warning("WARNING: grouped events cpus do not match.\n" > > + "Events with CPUs not matching the leader will " > > + "be removed from the group.\n"); > > + evsel__group_desc(leader, buf, sizeof(buf)); > > + pr_warning(" %s\n", buf); > > + warned_leader = leader; > > + } > > if (verbose > 0) { > > + char buf[200]; > > + > > cpu_map__snprint(leader->core.cpus, buf, sizeof(buf)); > > pr_warning(" %s: %s\n", leader->name, buf); > > cpu_map__snprint(evsel->core.cpus, buf, sizeof(buf)); > > pr_warning(" %s: %s\n", evsel->name, buf); > > } > > > > - for_each_group_evsel(pos, leader) > > - evsel__remove_from_group(pos, leader); > > + evsel__remove_from_group(evsel, leader); > > } > > } > >
On 2023-03-03 11:44 a.m., Ian Rogers wrote: > On Fri, Mar 3, 2023 at 7:50 AM Liang, Kan <kan.liang@linux.intel.com> wrote: >> >> >> >> On 2023-03-02 4:25 p.m., Ian Rogers wrote: >>> If the events in an evlist's CPU map differ then the entire group is >>> removed. For example: >>> >>> ``` >>> $ perf stat -e '{imc_free_running/data_read/,imc_free_running/data_write/,cs}' -a sleep 1 >>> WARNING: grouped events cpus do not match, disabling group: >>> anon group { imc_free_running/data_read/, imc_free_running/data_write/, cs } >>> ``` >>> >>> Change the behavior so that just the events not matching the leader >>> are removed. So in the example above, just 'cs' will be removed. >>> >>> Modify the warning so that it is produced once for each group, rather >>> than once for the entire evlist. Shrink the scope and size of the >>> warning text buffer. >> >> For the uncore, we usually have to create a group for each uncore PMU. >> The number of groups may be big. For example, on ICX, we have 40 CHA >> PMUs. For SPR, there should be more CHAs. If we have something like >> {cycles,uncore_cha/event=0x1/}, is the warning shown 40 times on ICX? >> If so, it should be very annoying. >> >> Maybe it's better to keep the current behavior which only print a >> warning once and notify the users that perf will re-group the events. >> For the details, they can get it from the -v option. > > Thanks Kan, I could imagine that but I was also worried about cases > where there are multiple groups like: > > ``` > $ perf stat -e '{imc_free_running/data_read/,cs},{uncore_clock/clockticks/,cs}' > -a sleep 1 > WARNING: grouped events cpus do not match. > Events with CPUs not matching the leader will be removed from the group. > anon group { imc_free_running/data_read/, cs } > WARNING: grouped events cpus do not match. > Events with CPUs not matching the leader will be removed from the group. > anon group { uncore_clock/clockticks/, cs } > > Performance counter stats for 'system wide': > > 1,255.75 MiB imc_free_running/data_read/ > 7,571 cs > 1,327,285,527 uncore_clock/clockticks/ > 7,571 cs > > 1.002772882 seconds time elapsed > ``` > > Knowing that both groups were broken there feels like a value add. > Given that this is a warning, and it can be fixed by moving the event > out of the group or forcing the CPUs, I lean toward being > informative/spammy as the spam is somewhat straightforwardly fixed on > the command line. I did some tests with the patch. The issue I was worried about didn't occur. The change looks good to me. But I found another issue. If I specify a CPU set, the group removal fails. It's not an issue of this patch. It looks like the current perf compares the user defined CPU set, rather than the PMU's cpumask. ./perf stat -e '{cycles,uncore_cha/event=0x1/}' -C0 sleep 1 Performance counter stats for 'CPU(s) 0': <not counted> cycles <not supported> uncore_cha/event=0x1/ 1.001783936 seconds time elapsed Some events weren't counted. Try disabling the NMI watchdog: echo 0 > /proc/sys/kernel/nmi_watchdog perf stat ... echo 1 > /proc/sys/kernel/nmi_watchdog The events in group usually have to be from the same PMU. Try reorganizing the group. Thanks, Kan > > Thanks, > Ian > >> Thanks, >> Kan >>> >>> Signed-off-by: Ian Rogers <irogers@google.com> >>> --- >>> tools/perf/builtin-stat.c | 24 +++++++++++++++--------- >>> 1 file changed, 15 insertions(+), 9 deletions(-) >>> >>> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c >>> index d70b1ec88594..5c12ae5efce5 100644 >>> --- a/tools/perf/builtin-stat.c >>> +++ b/tools/perf/builtin-stat.c >>> @@ -181,14 +181,13 @@ static bool cpus_map_matched(struct evsel *a, struct evsel *b) >>> >>> static void evlist__check_cpu_maps(struct evlist *evlist) >>> { >>> - struct evsel *evsel, *pos, *leader; >>> - char buf[1024]; >>> + struct evsel *evsel, *warned_leader = NULL; >>> >>> if (evlist__has_hybrid(evlist)) >>> evlist__warn_hybrid_group(evlist); >>> >>> evlist__for_each_entry(evlist, evsel) { >>> - leader = evsel__leader(evsel); >>> + struct evsel *leader = evsel__leader(evsel); >>> >>> /* Check that leader matches cpus with each member. */ >>> if (leader == evsel) >>> @@ -197,19 +196,26 @@ static void evlist__check_cpu_maps(struct evlist *evlist) >>> continue; >>> >>> /* If there's mismatch disable the group and warn user. */ >>> - WARN_ONCE(1, "WARNING: grouped events cpus do not match, disabling group:\n"); >>> - evsel__group_desc(leader, buf, sizeof(buf)); >>> - pr_warning(" %s\n", buf); >>> - >>> + if (warned_leader != leader) { >>> + char buf[200]; >>> + >>> + pr_warning("WARNING: grouped events cpus do not match.\n" >>> + "Events with CPUs not matching the leader will " >>> + "be removed from the group.\n"); >>> + evsel__group_desc(leader, buf, sizeof(buf)); >>> + pr_warning(" %s\n", buf); >>> + warned_leader = leader; >>> + } >>> if (verbose > 0) { >>> + char buf[200]; >>> + >>> cpu_map__snprint(leader->core.cpus, buf, sizeof(buf)); >>> pr_warning(" %s: %s\n", leader->name, buf); >>> cpu_map__snprint(evsel->core.cpus, buf, sizeof(buf)); >>> pr_warning(" %s: %s\n", evsel->name, buf); >>> } >>> >>> - for_each_group_evsel(pos, leader) >>> - evsel__remove_from_group(pos, leader); >>> + evsel__remove_from_group(evsel, leader); >>> } >>> } >>>
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c index d70b1ec88594..5c12ae5efce5 100644 --- a/tools/perf/builtin-stat.c +++ b/tools/perf/builtin-stat.c @@ -181,14 +181,13 @@ static bool cpus_map_matched(struct evsel *a, struct evsel *b) static void evlist__check_cpu_maps(struct evlist *evlist) { - struct evsel *evsel, *pos, *leader; - char buf[1024]; + struct evsel *evsel, *warned_leader = NULL; if (evlist__has_hybrid(evlist)) evlist__warn_hybrid_group(evlist); evlist__for_each_entry(evlist, evsel) { - leader = evsel__leader(evsel); + struct evsel *leader = evsel__leader(evsel); /* Check that leader matches cpus with each member. */ if (leader == evsel) @@ -197,19 +196,26 @@ static void evlist__check_cpu_maps(struct evlist *evlist) continue; /* If there's mismatch disable the group and warn user. */ - WARN_ONCE(1, "WARNING: grouped events cpus do not match, disabling group:\n"); - evsel__group_desc(leader, buf, sizeof(buf)); - pr_warning(" %s\n", buf); - + if (warned_leader != leader) { + char buf[200]; + + pr_warning("WARNING: grouped events cpus do not match.\n" + "Events with CPUs not matching the leader will " + "be removed from the group.\n"); + evsel__group_desc(leader, buf, sizeof(buf)); + pr_warning(" %s\n", buf); + warned_leader = leader; + } if (verbose > 0) { + char buf[200]; + cpu_map__snprint(leader->core.cpus, buf, sizeof(buf)); pr_warning(" %s: %s\n", leader->name, buf); cpu_map__snprint(evsel->core.cpus, buf, sizeof(buf)); pr_warning(" %s: %s\n", evsel->name, buf); } - for_each_group_evsel(pos, leader) - evsel__remove_from_group(pos, leader); + evsel__remove_from_group(evsel, leader); } }