From: Will Deacon <will@kernel.org>
To: Shaokun Zhang <zhangshaokun@hisilicon.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: perf: Expose some new events via sysfs
Date: Mon, 4 May 2020 08:06:25 +0100 [thread overview]
Message-ID: <20200504070624.GB2183@willie-the-truck> (raw)
In-Reply-To: <970b8ae4-fd9a-d5d1-0066-92152ff07fd5@hisilicon.com>
On Mon, May 04, 2020 at 11:46:14AM +0800, Shaokun Zhang wrote:
> Hi Will,
>
> One more question;-)
>
> On 2020/5/2 1:12, Will Deacon wrote:
> > On Tue, Apr 21, 2020 at 02:31:53PM +0800, Shaokun Zhang wrote:
> >> Some new PMU events can been detected by PMCEID1_EL0, but it can't
> >> be listed, Let's expose these through sysfs.
> >>
> >> Cc: Will Deacon <will@kernel.org>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
> >> ---
> >> arch/arm64/include/asm/perf_event.h | 19 +++++++++++++++++++
> >> arch/arm64/kernel/perf_event.c | 19 +++++++++++++++++++
> >> 2 files changed, 38 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> >> index e7765b62c712..f1b93d7c4260 100644
> >> --- a/arch/arm64/include/asm/perf_event.h
> >> +++ b/arch/arm64/include/asm/perf_event.h
> >> @@ -72,12 +72,31 @@
> >> #define ARMV8_PMUV3_PERFCTR_LL_CACHE_RD 0x36
> >> #define ARMV8_PMUV3_PERFCTR_LL_CACHE_MISS_RD 0x37
> >> #define ARMV8_PMUV3_PERFCTR_REMOTE_ACCESS_RD 0x38
> >> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_LMISS_RD 0x39
> >> +#define ARMV8_PMUV3_PERFCTR_OP_RETIRED 0x3A
> >> +#define ARMV8_PMUV3_PERFCTR_OP_SPEC 0x3B
> >> +#define ARMV8_PMUV3_PERFCTR_STALL 0x3C
> >> +#define ARMV8_PMUV3_PERFCTR_STALL_SLOT_BACKEND 0x3D
> >> +#define ARMV8_PMUV3_PERFCTR_STALL_SLOT_FRONTEND 0x3E
> >> +#define ARMV8_PMUV3_PERFCTR_STALL_SLOT 0x3F
> >
> > Hmm, looks like the presence of this event implies the presence of the
> > PMMIR_EL1 register. Should we be exposing the "SLOTS" field from that in
> > sysfs? (obviously as a separate patch)
> >
>
> Shall I expose it in /sys/devices/system/cpu/cpuX/regs/, right?
No; if we need to expose it (do we?) then it should be alongside the other
PMU files. e.g. /sys/bus/event_source/$pmu_name/caps/slots
Will
_______________________________________________
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:[~2020-05-04 7:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 6:31 [PATCH] arm64: perf: Expose some new events via sysfs Shaokun Zhang
2020-05-01 17:12 ` Will Deacon
2020-05-04 1:31 ` Shaokun Zhang
2020-05-04 3:46 ` Shaokun Zhang
2020-05-04 7:06 ` Will Deacon [this message]
2020-05-05 2:21 ` Shaokun Zhang
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=20200504070624.GB2183@willie-the-truck \
--to=will@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=zhangshaokun@hisilicon.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