Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1663880 > unrolled thread

Re: [PATCH v4 0/5] Add support for the ARMv8.2 Statistical Profiling Extension

Started byKim Phillips <kim.phillips@arm.com>
First post2017-06-12 18:30 +0200
Last post2017-06-15 18:00 +0200
Articles 2 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v4 0/5] Add support for the ARMv8.2 Statistical  Profiling Extension Kim Phillips <kim.phillips@arm.com> - 2017-06-12 18:30 +0200
    Re: [PATCH v4 0/5] Add support for the ARMv8.2 Statistical  Profiling Extension Kim Phillips <kim.phillips@arm.com> - 2017-06-15 18:00 +0200

#1663880 — Re: [PATCH v4 0/5] Add support for the ARMv8.2 Statistical Profiling Extension

FromKim Phillips <kim.phillips@arm.com>
Date2017-06-12 18:30 +0200
SubjectRe: [PATCH v4 0/5] Add support for the ARMv8.2 Statistical Profiling Extension
Message-ID<tRAo2-4qP-7@gated-at.bofh.it>
On Mon, 12 Jun 2017 12:08:23 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> On Mon, Jun 05, 2017 at 04:22:52PM +0100, Will Deacon wrote:
> > This is the sixth posting of the patches previously posted here:
> > 
> >   rfcv1: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/476450.html
> >   rfcv2: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/479387.html
> >      v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/483684.html
> >      v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/499938.html
> >      v3: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507132.html
> > 
> > The main change since v3 is that I have reworked and fixed the CPU hotplug
> > and notifier bits, in light of review comments from tglx.
> > 
> > The architecture documentation is available here:
> > 
> >   https://developer.arm.com/products/architecture/a-profile/docs/ddi0586/latest/arm-architecture-reference-manual-supplement-statistical-profiling-extension-for-armv8-a
> 
> Kim, do you have any version of the userspace side that we could look
> at?
> 
> For review, it would be really helpful to have something that can poke
> the PMU, even if it's incomplete or lacking polish.

Here's the latest push, based on a a couple of prior versions of this
driver:

http://linux-arm.org/git?p=linux-kp.git;a=shortlog;h=refs/heads/armspev0.1

I don't seem to be able to get any SPE data output after rebasing on
this version of the driver.  Still don't know why at the moment...

Kim

[toc] | [next] | [standalone]


#1666817

FromKim Phillips <kim.phillips@arm.com>
Date2017-06-15 18:00 +0200
Message-ID<tSFlE-4iZ-13@gated-at.bofh.it>
In reply to#1663880
On Mon, 12 Jun 2017 11:20:48 -0500
Kim Phillips <kim.phillips@arm.com> wrote:

> On Mon, 12 Jun 2017 12:08:23 +0100
> Mark Rutland <mark.rutland@arm.com> wrote:
> 
> > On Mon, Jun 05, 2017 at 04:22:52PM +0100, Will Deacon wrote:
> > > This is the sixth posting of the patches previously posted here:
...
> > Kim, do you have any version of the userspace side that we could look
> > at?
> > 
> > For review, it would be really helpful to have something that can poke
> > the PMU, even if it's incomplete or lacking polish.
> 
> Here's the latest push, based on a a couple of prior versions of this
> driver:
> 
> http://linux-arm.org/git?p=linux-kp.git;a=shortlog;h=refs/heads/armspev0.1
> 
> I don't seem to be able to get any SPE data output after rebasing on
> this version of the driver.  Still don't know why at the moment...

Bisected to commit e38ba76deef "perf tools: force uncore events to
system wide monitoring".  So, using record with specifying a -C
<cpu> explicitly now produces SPE data, but only a couple of valid
records at the beginning of each buffer; the rest is filled with
PADding (0's).

I see Mark's latest comments have found a possible issue in the perf
aux buffer handling code in the driver, and that the driver does some
memset of padding (0's) itself; could that be responsible for the above
behaviour?

Thanks,

Kim

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web