All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events.
Date: Mon, 1 Oct 2018 15:29:15 +0100	[thread overview]
Message-ID: <20181001142914.GD9716@arm.com> (raw)
In-Reply-To: <20181001100707.16840-1-ganapatrao.kulkarni@cavium.com>

Hi Ganapat,

On Mon, Oct 01, 2018 at 10:07:43AM +0000, Kulkarni, Ganapatrao wrote:
> Perf events L1-dcache-load-misses, L1-dcache-store-misses are mapped to
> armv8_pmuv3 (both DT and ACPI) event L1D_CACHE_REFILL. This is incorrect,
> since L1D_CACHE_REFILL counts both load and store misses.
> Similarly the events L1-dcache-loads, L1-dcache-stores, dTLB-load-misses
> and dTLB-loads are wrongly mapped. Hence Deleting all these cache events
> from armv8_pmuv3 cache mapping.
> 
> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> ---
>  arch/arm64/kernel/perf_event.c | 8 --------
>  1 file changed, 8 deletions(-)

The "generic" events are really implemented on a best-effort basis, as
they rarely tend to map exactly to what the hardware supports. I think
they originally stemmed from the x86 CPU PMU, but that doesn't really
help us.

I had a discussion with Ingo back when we originally implemented perf
because I actually preferred not to implement the generic events at all.
However, he was strongly of the opinion that a best-effort approach was
sufficient to get casual users going with the tool, so that's what we went
with.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: "Kulkarni, Ganapatrao" <Ganapatrao.Kulkarni@cavium.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"Nair, Jayachandran" <Jayachandran.Nair@cavium.com>,
	"Richter, Robert" <Robert.Richter@cavium.com>,
	"Lomovtsev, Vadim" <Vadim.Lomovtsev@cavium.com>,
	Jan Glauber <Jan.Glauber@cavium.com>,
	"gklkml16@gmail.com" <gklkml16@gmail.com>
Subject: Re: [PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events.
Date: Mon, 1 Oct 2018 15:29:15 +0100	[thread overview]
Message-ID: <20181001142914.GD9716@arm.com> (raw)
In-Reply-To: <20181001100707.16840-1-ganapatrao.kulkarni@cavium.com>

Hi Ganapat,

On Mon, Oct 01, 2018 at 10:07:43AM +0000, Kulkarni, Ganapatrao wrote:
> Perf events L1-dcache-load-misses, L1-dcache-store-misses are mapped to
> armv8_pmuv3 (both DT and ACPI) event L1D_CACHE_REFILL. This is incorrect,
> since L1D_CACHE_REFILL counts both load and store misses.
> Similarly the events L1-dcache-loads, L1-dcache-stores, dTLB-load-misses
> and dTLB-loads are wrongly mapped. Hence Deleting all these cache events
> from armv8_pmuv3 cache mapping.
> 
> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> ---
>  arch/arm64/kernel/perf_event.c | 8 --------
>  1 file changed, 8 deletions(-)

The "generic" events are really implemented on a best-effort basis, as
they rarely tend to map exactly to what the hardware supports. I think
they originally stemmed from the x86 CPU PMU, but that doesn't really
help us.

I had a discussion with Ingo back when we originally implemented perf
because I actually preferred not to implement the generic events at all.
However, he was strongly of the opinion that a best-effort approach was
sufficient to get casual users going with the tool, so that's what we went
with.

Will

  reply	other threads:[~2018-10-01 14:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-01 10:07 [PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events Kulkarni, Ganapatrao
2018-10-01 10:07 ` Kulkarni, Ganapatrao
2018-10-01 14:29 ` Will Deacon [this message]
2018-10-01 14:29   ` Will Deacon
2018-10-01 16:39   ` Ganapatrao Kulkarni
2018-10-01 16:39     ` Ganapatrao Kulkarni
2018-10-04  5:42     ` Ganapatrao Kulkarni
2018-10-04  5:42       ` Ganapatrao Kulkarni
2018-10-04 12:22       ` Will Deacon
2018-10-04 12:22         ` Will Deacon
2018-10-04 19:39         ` Ganapatrao Kulkarni
2018-10-04 19:39           ` Ganapatrao Kulkarni
2018-10-05 13:34           ` Will Deacon
2018-10-05 13:34             ` Will Deacon
2018-10-05 12:27         ` John Garry
2018-10-05 12:27           ` John Garry
2018-10-05 12:39           ` Will Deacon
2018-10-05 12:39             ` 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=20181001142914.GD9716@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.