[PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

[Madhavan Srinivasan]

On Thursday 01 September 2016 12:56 PM, Peter Zijlstra wrote:
> On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
>> It's a perennial request from hardware folks to be able to
>> see the raw values of the pmu registers. Partly it's so that
>> they can verify perf is doing what they want, and some
>> of it is that they're interested in some of the more obscure
>> info that isn't plumbed out through other perf interfaces.
> How much and what is that? Can't we try and get interfaces sorted?

We have bunch of registers which exports information regarding the
sampled instruction like SIER/SIAR/SDAR/MMCRA. Lot of bits in these
registers are not yet architected and incase of SIER register, some of
the bits are not plumbed out and we are working on getting some these
exposed via perf.

>
>> Over the years internally have used various hack to get
>> the requested data out but this is an attempt to use a
>> somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).
> Not really liking that. It assumes too much and doesn't seem to cover
> about half the perf use-cases.
>
> It assumes the machine state can be captured by registers (this is false
> for things like Intel DS/PT, which have state in memory), it might
> assume <= 64 registers but I didn't look that closely, this too might
> become somewhat restrictive.
>
> Worse, it doesn't work for !sampling workloads, of which you also very
> much want to verify programming etc.

Yes, I agree, my bad. I did assume and implemented considering
pmu registers primarily, but we can extend with additional flags
on the content being copied. Good point that patchset not handling
!sampling case. Let me explore on this and also the tracing options.

Thanks for the comments.
Maddy

>
>> This would also be helpful for those of us working on the perf
>> hardware backends, to be able to verify that we're programming
>> things correctly, without resorting to debug printks etc.
> On x86 we can trace the MSR writes. No need to add debug printk()s.
> We could (and I have on occasion) added tracepoints (well trace_printk)
> to the Intel DS memory stores to see what was written there.
>
> Tracing is much more flexible for debugging this stuff.
>
> Can't you do something along those lines?
>