From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-kernel@vger.kernel.org, Hector Martin <marcan@marcan.st>,
Ian Rogers <irogers@google.com>,
acme@redhat.com, james.clark@arm.com, john.g.garry@oracle.com,
leo.yan@linaro.org, linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, mike.leach@linaro.org,
namhyung@kernel.org, suzuki.poulose@arm.com,
tmricht@linux.ibm.com, will@kernel.org
Subject: Re: [PATCH] perf print-events: make is_event_supported() more robust
Date: Fri, 26 Jan 2024 14:36:16 +0000 [thread overview]
Message-ID: <ZbPDYG2Bd2H7C_Es@FVFF77S0Q05N> (raw)
In-Reply-To: <ZafEFU7kwf6W0_Qx@FVFF77S0Q05N.cambridge.arm.com>
On Wed, Jan 17, 2024 at 12:12:05PM +0000, Mark Rutland wrote:
> On Wed, Jan 17, 2024 at 09:05:25AM +0000, Marc Zyngier wrote:
> > However, I'm seeing some slightly odd behaviours:
I believe that this is a separate issue; info dump below.
> > $ sudo ./perf stat -e cycles:k ~/hackbench 100 process 1000
> > Running with 100*40 (== 4000) tasks.
> > Time: 3.313
> >
> > Performance counter stats for '/home/maz/hackbench 100 process 1000':
> >
> > <not supported> apple_firestorm_pmu/cycles:k/
> > <not supported> apple_icestorm_pmu/cycles:k/
> >
> > 3.467568841 seconds time elapsed
> >
> > 13.080111000 seconds user
> > 53.162099000 seconds sys
> >
> > I would have expected it to count, but it didn't. For that to work, I
> > have to add the 'H' modifier:
I gave that a spin with the aforementioned hacked-up PMUv3 driver, and I see
the same:
| # ./perf-after stat -e cycles true
|
| Performance counter stats for 'true':
|
| <not counted> armv8_pmuv3_0/cycles/ (0.00%)
| 1375271 armv8_pmuv3_1/cycles/
|
| 0.001153070 seconds time elapsed
|
| 0.001204000 seconds user
| 0.000000000 seconds sys
|
|
| # ./perf-after stat -e cycles:k true
|
| Performance counter stats for 'true':
|
| <not supported> armv8_pmuv3_0/cycles:k/
| <not supported> armv8_pmuv3_1/cycles:k/
|
| 0.000983130 seconds time elapsed
|
| 0.001037000 seconds user
| 0.000000000 seconds sys
|
|
| # ./perf-after stat -e cycles:kH true
|
| Performance counter stats for 'true':
|
| <not counted> armv8_pmuv3_0/cycles:kH/ (0.00%)
| 932067 armv8_pmuv3_1/cycles:kH/
|
| 0.001090100 seconds time elapsed
|
| 0.001125000 seconds user
| 0.000000000 seconds sys
... though interestingly 'cycles:u' works:
| # ./perf-after stat -e cycles:u true
|
| Performance counter stats for 'true':
|
| 369753 armv8_pmuv3_0/cycles:u/
| <not counted> armv8_pmuv3_1/cycles:u/ (0.00%)
|
| 0.001171980 seconds time elapsed
|
| 0.001245000 seconds user
| 0.000000000 seconds sys
Looking at the output with '-vvv' the perf tool implicitly sets exclude_guest
for 'cycles', 'cycles:u', and 'cycles:kH', but does not set exclude_guest for
'cycles:k'.
It looks like that's consistent with the behaviour of opening separate events
prior to this patch:
| # ./perf-before stat -e armv8_pmuv3_0/cycles/ -e armv8_pmuv3_1/cycles/ true
|
| Performance counter stats for 'true':
|
| 1407624 armv8_pmuv3_0/cycles/
| <not counted> armv8_pmuv3_1/cycles/ (0.00%)
|
| 0.001179205 seconds time elapsed
|
| 0.001217000 seconds user
| 0.000000000 seconds sys
|
|
| # ./perf-before stat -e armv8_pmuv3_0/cycles/u -e armv8_pmuv3_1/cycles/u true
|
| Performance counter stats for 'true':
|
| 329212 armv8_pmuv3_0/cycles/u
| <not counted> armv8_pmuv3_1/cycles/u (0.00%)
|
| 0.001050550 seconds time elapsed
|
| 0.001081000 seconds user
| 0.000000000 seconds sys
|
|
| # ./perf-before stat -e armv8_pmuv3_0/cycles/k -e armv8_pmuv3_1/cycles/k true
|
| Performance counter stats for 'true':
|
| <not supported> armv8_pmuv3_0/cycles/k
| <not supported> armv8_pmuv3_1/cycles/k
|
| 0.000944285 seconds time elapsed
|
| 0.000985000 seconds user
| 0.000000000 seconds sys
|
|
| # ./perf-before stat -e armv8_pmuv3_0/cycles/kH -e armv8_pmuv3_1/cycles/kH true
|
| Performance counter stats for 'true':
|
| 1016160 armv8_pmuv3_0/cycles/kH
| <not counted> armv8_pmuv3_1/cycles/kH (0.00%)
|
| 0.001179220 seconds time elapsed
|
| 0.001239000 seconds user
| 0.000000000 seconds sys
... and per '-vvv', exclude_guest is set in the same cases.
I agree it's a bit weird that the tool sets exclude_guest for unfilted and ':u'
events, but not ':k' events, but it looks like that's separate from the way
events get expanded.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-26 14:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 17:03 [PATCH] perf print-events: make is_event_supported() more robust Mark Rutland
2024-01-17 9:05 ` Marc Zyngier
2024-01-17 12:12 ` Mark Rutland
2024-01-19 5:57 ` Namhyung Kim
2024-01-24 16:05 ` Mark Rutland
2024-01-26 14:36 ` Mark Rutland [this message]
2024-01-19 15:00 ` James Clark
2024-01-20 18:27 ` Ian Rogers
2024-01-20 18:29 ` Ian Rogers
2024-01-24 15:51 ` Mark Rutland
2024-01-24 15:48 ` Mark Rutland
2024-01-22 10:43 ` James Clark
2024-01-24 15:53 ` Mark Rutland
2024-01-24 16:19 ` James Clark
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=ZbPDYG2Bd2H7C_Es@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=acme@redhat.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=john.g.garry@oracle.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=maz@kernel.org \
--cc=mike.leach@linaro.org \
--cc=namhyung@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tmricht@linux.ibm.com \
--cc=will@kernel.org \
/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