From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932902AbcIADJG (ORCPT ); Wed, 31 Aug 2016 23:09:06 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:50765 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754571AbcIADJE (ORCPT ); Wed, 31 Aug 2016 23:09:04 -0400 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: maddy@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/13] Add support for perf_arch_regs To: Nilay Vaish References: <1472418058-28659-1-git-send-email-maddy@linux.vnet.ibm.com> Cc: Linux Kernel list , linuxppc-dev@lists.ozlabs.org From: Madhavan Srinivasan Date: Thu, 1 Sep 2016 08:38:56 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16090103-0004-0000-0000-0000018DDAC4 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16090103-0005-0000-0000-0000089577E4 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-01_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609010029 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 30 August 2016 09:31 PM, Nilay Vaish wrote: > On 28 August 2016 at 16:00, Madhavan Srinivasan > wrote: >> Patchset to extend PERF_SAMPLE_REGS_INTR to include >> platform specific PMU registers. >> >> Patchset applies cleanly on tip:perf/core branch >> >> 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. >> >> Over the years internally we 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). >> >> 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. >> >> Mechanism proposed: >> >> 1)perf_regs structure is extended with a perf_arch_regs structure >> which each arch/ can populate with their specific platform >> registers to sample on each perf interrupt and an arch_regs_mask >> variable, which is for perf tool to know about the perf_arch_regs >> that are supported. >> >> 2)perf/core func perf_sample_regs_intr() extended to update >> the perf_arch_regs structure and the perf_arch_reg_mask. Set of new >> support functions added perf_get_arch_regs_mask() and >> perf_get_arch_reg() to aid the updates from arch/ side. >> >> 3) perf/core funcs perf_prepare_sample() and perf_output_sample() >> are extended to support the update for the perf_arch_regs_mask and >> perf_arch_regs in the sample >> >> 4)perf/core func perf_output_sample_regs() extended to dump >> the arch_regs to the output sample. >> >> 5)Finally, perf tool side is updated to include a new element >> "arch_regs_mask" in the "struct regs_dump", event sample funcs >> and print functions are updated to support perf_arch_regs. >> > I read the patch series and I have one suggestion to make. I think we > should not use 'arch regs' to refer to these pmu registers. I think Reason is that they are arch specific pmu regs. But I guess we can go with pmu_regs also. And having a "pregs" as option to list in -I? will be fine? (patch 13 in the patch series) Maddy > architectural registers typically refer to the ones that hold the > state of the process. Can we replace arch_regs by pmu_regs, or some > other choice? > > Thanks > Nilay >