Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756011Ab0BATyy (ORCPT ); Mon, 1 Feb 2010 14:54:54 -0500 Received: from casper.infradead.org ([85.118.1.10]:35551 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754876Ab0BATyw (ORCPT ); Mon, 1 Feb 2010 14:54:52 -0500 Subject: Re: [RFC] perf_events: support for uncore a.k.a. nest units From: Peter Zijlstra To: Corey Ashford Cc: Ingo Molnar , LKML , Andi Kleen , Paul Mackerras , Stephane Eranian , Frederic Weisbecker , Xiao Guangrong , Dan Terpstra , Philip Mucci , Maynard Johnson , Carl Love , Steven Rostedt , Arnaldo Carvalho de Melo , Masami Hiramatsu In-Reply-To: <4B672DEE.8000804@linux.vnet.ibm.com> References: <4B560ACD.4040206@linux.vnet.ibm.com> <1263994448.4283.1052.camel@laptop> <1264023204.4283.1124.camel@laptop> <4B57907E.5000207@linux.vnet.ibm.com> <20100121072118.GA10585@elte.hu> <4B58A750.2060607@linux.vnet.ibm.com> <4B58AAF7.60507@linux.vnet.ibm.com> <20100127102834.GA27357@elte.hu> <4B60990C.1030804@linux.vnet.ibm.com> <1264676244.4283.2093.camel@laptop> <4B61D0CB.4090809@linux.vnet.ibm.com> <1264705607.4283.2120.camel@laptop> <4B620AD4.8000108@linux.vnet.ibm.com> <1264758747.4283.2150.camel@laptop> <4B6369B2.1060508@linux.vnet.ibm.com> <1264840979.24455.51.camel@laptop> <4B672DEE.8000804@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 01 Feb 2010 20:54:21 +0100 Message-ID: <1265054061.24455.244.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1482 Lines: 33 On Mon, 2010-02-01 at 11:39 -0800, Corey Ashford wrote: > > On 1/30/2010 12:42 AM, Peter Zijlstra wrote: > > On Fri, 2010-01-29 at 15:05 -0800, Corey Ashford wrote: > >> So you'd read the id from the sysfs topology tree, and then pass that id to the > >> interface? That's an interesting approach that eliminates the need to pass a > >> string pmu path to the kernel. > > > > No, the attr.pmu_id would reflect the location in the tree (pci > > location, or spu number), the pmu id reported would identify the kind of > > pmu driver used for that particular device. > > > > I realized this confusion after sending but didn't clarify, we should > > come up with a good alternative name for either (or both) uses. > > > > Ok, just so I'm clear here, is attr.pmu_id a (char *) or some sort of encoded > bit field? Right, currently on x86 we have x86_pmu.name which basically tells us what kind of pmu it is, but we really don't export that since its trivial to see that from /proc/cpuinfo, but the ARM people expressed interest in this because decoding the cpuid equivalent on arm is like nasty business. But once we go add other funny pmu's, it becomes interesting to know what kind of pmu it is and tie possible event sets to them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/