From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754737AbcIAH0z (ORCPT ); Thu, 1 Sep 2016 03:26:55 -0400 Received: from merlin.infradead.org ([205.233.59.134]:47766 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754282AbcIAH0x (ORCPT ); Thu, 1 Sep 2016 03:26:53 -0400 Date: Thu, 1 Sep 2016 09:26:29 +0200 From: Peter Zijlstra To: Madhavan Srinivasan Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Thomas Gleixner , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Stephane Eranian , Russell King , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Michael Ellerman , Sukadev Bhattiprolu Subject: Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure Message-ID: <20160901072629.GJ10153@twins.programming.kicks-ass.net> References: <1472418058-28659-1-git-send-email-maddy@linux.vnet.ibm.com> <1472418058-28659-2-git-send-email-maddy@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1472418058-28659-2-git-send-email-maddy@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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. > 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?