From: acme@redhat.com (Arnaldo Carvalho de Melo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 6/7] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
Date: Mon, 2 Oct 2017 13:49:30 -0300 [thread overview]
Message-ID: <20171002164930.GB2121@redhat.com> (raw)
In-Reply-To: <20171002141405.GC12847@arm.com>
Em Mon, Oct 02, 2017 at 03:14:05PM +0100, Will Deacon escreveu:
> On Fri, Sep 29, 2017 at 05:19:40PM -0500, Kim Phillips wrote:
> > On Thu, 28 Sep 2017 15:09:50 +0100
> > Will Deacon <will.deacon@arm.com> wrote:
> > > + if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0)
> > > + return -EOPNOTSUPP;
> > > + if (attr->exclude_idle)
> > > + return -EOPNOTSUPP;
> > "PMU Hardware doesn't support sampling/overflow-interrupts." will be
> > printed if the user didn't specify a sample period. Otherwise, a
> > string with "/bin/dmesg may provide additional information." will be
> > printed.
> > I was hoping for a response from acme by now for this:
> > https://www.spinics.net/lists/linux-perf-users/msg04066.html
> > Alas, nothing. Looking at the #ifdef x86 in evsel.c, I'm guessing
> > it'll be ok, although I'm still not sure how PMU-specific we can get in
> > evsel.c, nor whether it's ok to communicate lists of h/w supported
> > sample periods through /sys/bus/event_source/devices/...
> >
> > acme? OK to refactor evsel messaging for Arm, including parsing for
> > which PMUs are being used, so customize the message?
>
> Arnaldo's probably got enough on his plate maintaining perf tool, so my
> advice would be to post a patch as an RFC and use that as a concrete basis
> for discussion. It often works out better starting with code, even if none
> of it ends up getting merged (and you can include bits of your email above
> in the cover letter).
I'm all for more informative messages, and if you guys agree on how to
provide the info in a way that combined with logic in evsel.c, I'd say
do what Will suggested, post a patch series and include usage examples,
before and after.
- Arnaldo
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Kim Phillips <kim.phillips@arm.com>,
linux-arm-kernel@lists.infradead.org, marc.zyngier@arm.com,
mark.rutland@arm.com, tglx@linutronix.de, peterz@infradead.org,
alexander.shishkin@linux.intel.com, robh@kernel.org,
suzuki.poulose@arm.com, pawel.moll@arm.com,
mathieu.poirier@linaro.org, mingo@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 6/7] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
Date: Mon, 2 Oct 2017 13:49:30 -0300 [thread overview]
Message-ID: <20171002164930.GB2121@redhat.com> (raw)
In-Reply-To: <20171002141405.GC12847@arm.com>
Em Mon, Oct 02, 2017 at 03:14:05PM +0100, Will Deacon escreveu:
> On Fri, Sep 29, 2017 at 05:19:40PM -0500, Kim Phillips wrote:
> > On Thu, 28 Sep 2017 15:09:50 +0100
> > Will Deacon <will.deacon@arm.com> wrote:
> > > + if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0)
> > > + return -EOPNOTSUPP;
> > > + if (attr->exclude_idle)
> > > + return -EOPNOTSUPP;
> > "PMU Hardware doesn't support sampling/overflow-interrupts." will be
> > printed if the user didn't specify a sample period. Otherwise, a
> > string with "/bin/dmesg may provide additional information." will be
> > printed.
> > I was hoping for a response from acme by now for this:
> > https://www.spinics.net/lists/linux-perf-users/msg04066.html
> > Alas, nothing. Looking at the #ifdef x86 in evsel.c, I'm guessing
> > it'll be ok, although I'm still not sure how PMU-specific we can get in
> > evsel.c, nor whether it's ok to communicate lists of h/w supported
> > sample periods through /sys/bus/event_source/devices/...
> >
> > acme? OK to refactor evsel messaging for Arm, including parsing for
> > which PMUs are being used, so customize the message?
>
> Arnaldo's probably got enough on his plate maintaining perf tool, so my
> advice would be to post a patch as an RFC and use that as a concrete basis
> for discussion. It often works out better starting with code, even if none
> of it ends up getting merged (and you can include bits of your email above
> in the cover letter).
I'm all for more informative messages, and if you guys agree on how to
provide the info in a way that combined with logic in evsel.c, I'd say
do what Will suggested, post a patch series and include usage examples,
before and after.
- Arnaldo
next prev parent reply other threads:[~2017-10-02 16:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 14:09 [PATCH v5 0/7] Add support for the ARMv8.2 Statistical Profiling Extension Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-09-28 14:09 ` [PATCH v5 1/7] genirq: export irq_get_percpu_devid_partition to modules Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-09-28 14:09 ` [PATCH v5 2/7] perf/core: Export AUX buffer helpers " Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-09-28 14:09 ` [PATCH v5 3/7] perf/core: Add PERF_AUX_FLAG_COLLISION to report colliding samples Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-09-28 14:09 ` [PATCH v5 4/7] arm64: sysreg: Move SPE registers and PSB into common header files Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-10-02 9:53 ` Marc Zyngier
2017-10-02 9:53 ` Marc Zyngier
2017-10-02 9:55 ` Mark Rutland
2017-10-02 9:55 ` Mark Rutland
2017-09-28 14:09 ` [PATCH v5 5/7] arm64: head: Init PMSCR_EL2.{PA, PCT} when entered at EL2 without VHE Will Deacon
2017-09-28 14:09 ` [PATCH v5 5/7] arm64: head: Init PMSCR_EL2.{PA,PCT} " Will Deacon
2017-10-02 10:03 ` [PATCH v5 5/7] arm64: head: Init PMSCR_EL2.{PA, PCT} " Mark Rutland
2017-10-02 10:03 ` [PATCH v5 5/7] arm64: head: Init PMSCR_EL2.{PA,PCT} " Mark Rutland
2017-09-28 14:09 ` [PATCH v5 6/7] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-09-29 22:19 ` Kim Phillips
2017-09-29 22:19 ` Kim Phillips
2017-10-02 14:14 ` Will Deacon
2017-10-02 14:14 ` Will Deacon
2017-10-02 16:49 ` Arnaldo Carvalho de Melo [this message]
2017-10-02 16:49 ` Arnaldo Carvalho de Melo
2017-10-02 23:35 ` Kim Phillips
2017-10-02 23:35 ` Kim Phillips
2017-10-03 14:22 ` Will Deacon
2017-10-03 14:22 ` Will Deacon
2017-10-24 8:42 ` Kim Phillips
2017-10-24 8:42 ` Kim Phillips
2017-09-28 14:09 ` [PATCH v5 7/7] dt-bindings: Document devicetree binding for ARM SPE Will Deacon
2017-09-28 14:09 ` Will Deacon
2017-10-02 10:07 ` Mark Rutland
2017-10-02 10:07 ` Mark Rutland
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=20171002164930.GB2121@redhat.com \
--to=acme@redhat.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.