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

From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Stephane Eranian <eranian@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Subject: Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure
Date: Fri, 9 Sep 2016 06:14:53 +0530	[thread overview]
Message-ID: <2bbb5bfe-d096-d82a-398e-0c2df4242d7b@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160906091042.GJ10153@twins.programming.kicks-ass.net>

On Tuesday 06 September 2016 02:40 PM, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 09:55:43AM +0530, Madhavan Srinivasan wrote:
>>
>> 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.
> What kind of information is this? I'm not familiar with the Power PMU
> all that much, so you'll have to spell it out, not just mention the
> registers its stuffed in.

Sure. When we profile for sample events,
SIER (Sampled Instruction Event Register) provides additional
information about the sampled event when PMI occurred.

SIER [41:42] indicates whether the SIAR(Sampled instruction address 
registers)
and SDAR (Sampled data address register) are valid for the sampled event.

SIER [46:48] indicates the type of intructions,

001 Load Instruction
010 Store instruction
011 Branch Instruction
100 Floating Point Instruction other than a Load or Store instruction
101 Fixed Point Instruction other than a Load or Store instruction
110 Condition Register or System Call Instruction

SIER[49:51] gives information on the source of the sampled
instruction like instruction came from primary, secondary,
tertiary cache or beyond.

SIER[52:55] provide information on branch type instructions
Like mispredict and cause of it.

SIER[56:59] provides information on translation and also
source of translation like TLB, secondary cache, tertiary
or beyond

SIER[60:62] provides the interesting data on the storage
access like L1/l2/L3... so on.

Most of these could be plumbed out through standard mechanisms
and it's all the other bits that are more interesting, but
these are not architected and not public.

Like wise, MMCRA (Monitor Mode Control Register A) is a
configuration register for sampling and thresholding events.
Provide data on various event configuration information.

Link to the PowerISA v2.07 and Chapters 9 describes in
detail on these registers.

https://www.power.org/wp-content/uploads/2013/05/PowerISA_V2.07_PUBLIC.pdf

Maddy

>