From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3
Date: Thu, 27 Apr 2017 18:36:42 +0100 [thread overview]
Message-ID: <20170427173642.GM1890@arm.com> (raw)
In-Reply-To: <28edde78-b965-8136-1c95-11b9182de405@gmail.com>
On Tue, Apr 25, 2017 at 10:13:51AM -0700, Florian Fainelli wrote:
> On 04/25/2017 05:44 AM, Will Deacon wrote:
> > Hi Florian,
> >
> > On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote:
> >> The ARMv8 PMUv3 cache map did not include the L2 cache events, add
> >> them.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> arch/arm64/kernel/perf_event.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> >> index 4f011cdd756d..a664c575f3fd 100644
> >> --- a/arch/arm64/kernel/perf_event.c
> >> +++ b/arch/arm64/kernel/perf_event.c
> >> @@ -264,6 +264,11 @@ static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
> >> [C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
> >> [C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
> >>
> >> + [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
> >> + [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
> >> + [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
> >> + [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
> >
> > I don't think this is correct in general. 'LL' stands for "last-level",
> > which may be L3 or even a system cache in the interconnect. Tying that to L2
> > is the wrong thing to do from perf's generic event perspective.
> >
> > I'm ok with what you're proposing for A53 (where the PMU can only count
> > events out to the L2), but I'm reluctant to make this change for the generic
> > PMUv3 events.
>
> That makes sense, shall I resubmit the first patch by itself or can you
> or Catalin take it as-is?
I'll talk to Catalin tomorrow and try to get the A53 bit queued.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org, alcooperx@gmail.com,
opendmb@gmail.com, Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Catalin Marinas <catalin.marinas@arm.com>,
"open list:PERFORMANCE EVENTS SUBSYSTEM"
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3
Date: Thu, 27 Apr 2017 18:36:42 +0100 [thread overview]
Message-ID: <20170427173642.GM1890@arm.com> (raw)
In-Reply-To: <28edde78-b965-8136-1c95-11b9182de405@gmail.com>
On Tue, Apr 25, 2017 at 10:13:51AM -0700, Florian Fainelli wrote:
> On 04/25/2017 05:44 AM, Will Deacon wrote:
> > Hi Florian,
> >
> > On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote:
> >> The ARMv8 PMUv3 cache map did not include the L2 cache events, add
> >> them.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> arch/arm64/kernel/perf_event.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> >> index 4f011cdd756d..a664c575f3fd 100644
> >> --- a/arch/arm64/kernel/perf_event.c
> >> +++ b/arch/arm64/kernel/perf_event.c
> >> @@ -264,6 +264,11 @@ static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
> >> [C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
> >> [C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
> >>
> >> + [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
> >> + [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
> >> + [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
> >> + [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
> >
> > I don't think this is correct in general. 'LL' stands for "last-level",
> > which may be L3 or even a system cache in the interconnect. Tying that to L2
> > is the wrong thing to do from perf's generic event perspective.
> >
> > I'm ok with what you're proposing for A53 (where the PMU can only count
> > events out to the L2), but I'm reluctant to make this change for the generic
> > PMUv3 events.
>
> That makes sense, shall I resubmit the first patch by itself or can you
> or Catalin take it as-is?
I'll talk to Catalin tomorrow and try to get the A53 bit queued.
Will
next prev parent reply other threads:[~2017-04-27 17:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 19:05 [PATCH 0/2] arm64: perf: Add L2 cache events for ARMv8 PMuv3 and A53 Florian Fainelli
2017-04-20 19:05 ` Florian Fainelli
2017-04-20 19:05 ` [PATCH 1/2] arm64: perf: Wire-up Cortex A53 L2 cache events and DTLB refills Florian Fainelli
2017-04-20 19:05 ` Florian Fainelli
2017-04-20 19:05 ` [PATCH 1/2] arm64: pmu: " Florian Fainelli
2017-04-20 19:05 ` Florian Fainelli
2017-04-20 19:05 ` [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3 Florian Fainelli
2017-04-20 19:05 ` Florian Fainelli
2017-04-25 12:44 ` Will Deacon
2017-04-25 12:44 ` Will Deacon
2017-04-25 17:13 ` Florian Fainelli
2017-04-25 17:13 ` Florian Fainelli
2017-04-27 17:36 ` Will Deacon [this message]
2017-04-27 17:36 ` Will Deacon
2017-04-28 14:15 ` Catalin Marinas
2017-04-28 14:15 ` Catalin Marinas
2017-04-28 14:17 ` Will Deacon
2017-04-28 14:17 ` Will Deacon
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=20170427173642.GM1890@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.