From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
To: acme@kernel.org, jolsa@kernel.org, adrian.hunter@intel.com,
irogers@google.com, namhyung@kernel.org, ravi.bangoria@amd.com
Cc: linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
maddy@linux.ibm.com, atrajeev@linux.vnet.ibm.com,
kjain@linux.ibm.com, disgoel@linux.vnet.ibm.com,
hbathini@linux.ibm.com, Tejas Manhas <Tejas.Manhas1@ibm.com>
Subject: [PATCH] tools/perf/tests: Update event_groups test to use instructions as one of the sibling event for hw type
Date: Fri, 10 Jan 2025 15:16:20 +0530 [thread overview]
Message-ID: <20250110094620.94976-1-atrajeev@linux.vnet.ibm.com> (raw)
In some of the powerpc platforms, event group testcase fails as below:
# perf test -v 'Event groups'
69: Event groups :
--- start ---
test child forked, pid 9765
Using CPUID 0x00820200
Using hv_24x7 for uncore pmu event
0x0 0x0, 0x0 0x0, 0x0 0x0: Fail
0x0 0x0, 0x0 0x0, 0x1 0x3: Pass
The testcase creates various combinations of hw, sw and uncore
PMU events and verify group creation succeeds or fails as expected.
This tests one of the limitation in perf where it doesn't allow
creating a group of events from different hw PMUs.
The testcase starts a leader event and opens two sibling events.
The combination the fails is three hardware events in a group.
"0x0 0x0, 0x0 0x0, 0x0 0x0: Fail"
Type zero and config zero which translates to PERF_TYPE_HARDWARE
and PERF_COUNT_HW_CPU_CYCLE. There is event constraint in powerpc
that events using same counter cannot be programmed in a group.
Here there is one alternative event for cycles, hence one leader
and only one sibling event can go in as a group.
if all three events (leader and two sibling events), are hardware
events, use instructions as one of the sibling event. Since
PERF_COUNT_HW_INSTRUCTIONS is a generic hardware event and present
in all architectures, use this as third event.
Reported-by: Tejas Manhas <Tejas.Manhas1@ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
tools/perf/tests/event_groups.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/tools/perf/tests/event_groups.c b/tools/perf/tests/event_groups.c
index ccd9d8b2903f..c119ff114948 100644
--- a/tools/perf/tests/event_groups.c
+++ b/tools/perf/tests/event_groups.c
@@ -10,9 +10,10 @@
#include "header.h"
#include "../perf-sys.h"
-/* hw: cycles, sw: context-switch, uncore: [arch dependent] */
+/* hw: cycles,instructions sw: context-switch, uncore: [arch dependent] */
static int types[] = {0, 1, -1};
static unsigned long configs[] = {0, 3, 0};
+static unsigned long configs_hw[] = {1};
#define NR_UNCORE_PMUS 5
@@ -93,7 +94,18 @@ static int run_test(int i, int j, int k)
return erroneous ? 0 : -1;
}
- sibling_fd2 = event_open(types[k], configs[k], group_fd);
+ /*
+ * if all three events (leader and two sibling events)
+ * are hardware events, use instructions as one of the
+ * sibling event. There is event constraint in powerpc that
+ * events using same counter cannot be programmed in a group.
+ * Since PERF_COUNT_HW_INSTRUCTIONS is a generic hardware
+ * event and present in all platforms, lets use that.
+ */
+ if (!i && !j && !k)
+ sibling_fd2 = event_open(types[k], configs_hw[k], group_fd);
+ else
+ sibling_fd2 = event_open(types[k], configs[k], group_fd);
if (sibling_fd2 == -1) {
close(sibling_fd1);
close(group_fd);
@@ -124,9 +136,18 @@ static int test__event_groups(struct test_suite *text __maybe_unused, int subtes
if (r)
ret = TEST_FAIL;
- pr_debug("0x%x 0x%lx, 0x%x 0x%lx, 0x%x 0x%lx: %s\n",
- types[i], configs[i], types[j], configs[j],
- types[k], configs[k], r ? "Fail" : "Pass");
+ /*
+ * For all three events as HW events, second sibling
+ * event is picked from configs_hw. So print accordingly
+ */
+ if (!i && !j && !k)
+ pr_debug("0x%x 0x%lx, 0x%x 0x%lx, 0x%x 0x%lx: %s\n",
+ types[i], configs[i], types[j], configs[j],
+ types[k], configs_hw[k], r ? "Fail" : "Pass");
+ else
+ pr_debug("0x%x 0x%lx, 0x%x 0x%lx, 0x%x 0x%lx: %s\n",
+ types[i], configs[i], types[j], configs[j],
+ types[k], configs[k], r ? "Fail" : "Pass");
}
}
}
--
2.43.5
next reply other threads:[~2025-01-10 9:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 9:46 Athira Rajeev [this message]
2025-01-20 6:30 ` [PATCH] tools/perf/tests: Update event_groups test to use instructions as one of the sibling event for hw type Ravi Bangoria
2025-01-20 8:23 ` Athira Rajeev
2025-01-20 9:38 ` Ravi Bangoria
2025-01-20 18:26 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250110094620.94976-1-atrajeev@linux.vnet.ibm.com \
--to=atrajeev@linux.vnet.ibm.com \
--cc=Tejas.Manhas1@ibm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=disgoel@linux.vnet.ibm.com \
--cc=hbathini@linux.ibm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kjain@linux.ibm.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=namhyung@kernel.org \
--cc=ravi.bangoria@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox