From nobody Thu Dec 18 22:15:19 2025 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 3F01EC19F20 for ; Tue, 2 May 2023 22:42:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230215AbjEBWmd (ORCPT ); Tue, 2 May 2023 18:42:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230172AbjEBWmG (ORCPT ); Tue, 2 May 2023 18:42:06 -0400 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 D26033C3D for ; Tue, 2 May 2023 15:41:43 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-b9a805e82a9so9887843276.3 for ; Tue, 02 May 2023 15:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683067295; x=1685659295; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Y7D6E0hATCK7e1RhJ0eODuZwXaDaxrE5gp17wu1kd6s=; b=D/bkUj+CvVAC7aYfNgnj4KG5nYd3eTAqh9e6DM0gZZCoQjFlJnRsvX7S3ZBoM9MfVM KovVZNSKZIy2UKW3qeC63Thp8iWn9rHXFjDF1VBowQR1A9soWiwMrXhk3BKdOYLbxIHi iy2ENXEPlZWq6HdDGDMhx6Fp+UZyezvplvUvthMQ3yN0+8U1X0zMaAvbBHvjg2hEzSGA 8RC+TbU+v1BSw9c8YFFtAevtcRnNXp+uQh7oL0j0PWWa7H+9zbM0fQaAiO6xVNMKOSC9 E/0k/1HdFn9HJrPvmmkZgc7CzWtGHCF3DM03VK8bXN+3zyxaRJG7karDc8BdJ147CuHc aKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683067295; x=1685659295; 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=Y7D6E0hATCK7e1RhJ0eODuZwXaDaxrE5gp17wu1kd6s=; b=gFadxnz/10jB0Hw3e7HaO18C9Hj9++5xsmstIBLXiYZzDVC3kvIrPjnlZqmvYwk3jU mekoVZ6CWWToUz5N1r8sr5klsNKNU2o5D8+6L00IXK4ygixo1SjTTHCmnii14ywIVpHa 75IDsYcaJ9pyHpQ3dRRr0rjDbaAgRa3WPOGNae975zCGbwMxkc5Xul0xVmNA5wGGr3n1 z1kbViqGnoutbL6uL3jJYggIrqTxZq4C5Z8pUNIn22IaXbhVrhZKrO3SBUpy1xXXk8pp XQ03fzEX0+frIKL2KS8G1Bd4H8/OQj9ITwLSAeXRxLzTXZFolNsOD+WPB+Z+2HTDLIpN K7xA== X-Gm-Message-State: AC+VfDxgWyfTjpev3NgSyexvNhJeRFqHyGU7R4yG+migCOtGKZ/cVnz5 5aWP+9wUdiwYXL15JY36AIYXzRa37gk6 X-Google-Smtp-Source: ACHHUZ7LYH229NyKNMZkZWsQienaXd755Yu/epnis0xg39gsfR3yA6p0IrF5aj4wIWeZaeopiMz6DL1RqYce X-Received: from irogers.svl.corp.google.com ([2620:15c:2d4:203:e70c:446b:d23b:982e]) (user=irogers job=sendgmr) by 2002:a25:d08a:0:b0:b99:34c:ab15 with SMTP id h132-20020a25d08a000000b00b99034cab15mr7544350ybg.1.1683067295712; Tue, 02 May 2023 15:41:35 -0700 (PDT) Date: Tue, 2 May 2023 15:38:26 -0700 In-Reply-To: <20230502223851.2234828-1-irogers@google.com> Message-Id: <20230502223851.2234828-20-irogers@google.com> Mime-Version: 1.0 References: <20230502223851.2234828-1-irogers@google.com> X-Mailer: git-send-email 2.40.1.495.gc816e09b53d-goog Subject: [PATCH v4 19/44] perf evsel: Modify group pmu name for software events From: Ian Rogers To: Arnaldo Carvalho de Melo , Kan Liang , Ahmad Yasin , Peter Zijlstra , Ingo Molnar , Stephane Eranian , Andi Kleen , Perry Taylor , Samantha Alt , Caleb Biggers , Weilin Wang , Edward Baker , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Adrian Hunter , Florian Fischer , Rob Herring , Zhengjun Xing , John Garry , Kajol Jain , Sumanth Korikkar , Thomas Richter , Tiezhu Yang , Ravi Bangoria , Leo Yan , Yang Jihong , James Clark , Suzuki Poulouse , Kang Minchul , Athira Rajeev , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Ian Rogers Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If we have a group of {cycles,faults} then we need the faults software event to appear to be on the same PMU as cycles so that we don't split the group in parse_events__sort_events_and_fix_groups. This case is relatively easy as cycles is the leader and will have a PMU name. In the reverse case, {faults,cycles} we still need faults to appear to have the PMU name of cycles but the old behavior is just to return "cpu". For hybrid this fails as cycles will be on "cpu_core" or "cpu_atom", causing faults to be split into a different group. Change the behavior for software events so that the whole group is searched for the named PMU. Signed-off-by: Ian Rogers --- tools/perf/util/evsel.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 1cd04b5998d2..63522322e118 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -829,23 +829,26 @@ bool evsel__name_is(struct evsel *evsel, const char *= name) =20 const char *evsel__group_pmu_name(const struct evsel *evsel) { - const struct evsel *leader; + struct evsel *leader, *pos; =20 /* If the pmu_name is set use it. pmu_name isn't set for CPU and software= events. */ if (evsel->pmu_name) return evsel->pmu_name; /* * Software events may be in a group with other uncore PMU events. Use - * the pmu_name of the group leader to avoid breaking the software event - * out of the group. + * the pmu_name of the first non-software event to avoid breaking the + * software event out of the group. * * Aux event leaders, like intel_pt, expect a group with events from * other PMUs, so substitute the AUX event's PMU in this case. */ leader =3D evsel__leader(evsel); - if ((evsel->core.attr.type =3D=3D PERF_TYPE_SOFTWARE || evsel__is_aux_eve= nt(leader)) && - leader->pmu_name) { - return leader->pmu_name; + if (evsel->core.attr.type =3D=3D PERF_TYPE_SOFTWARE || evsel__is_aux_even= t(leader)) { + /* Starting with the leader, find the first event with a named PMU. */ + for_each_group_evsel(pos, leader) { + if (pos->pmu_name) + return pos->pmu_name; + } } =20 return "cpu"; --=20 2.40.1.495.gc816e09b53d-goog