From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753454Ab0EMIjO (ORCPT ); Thu, 13 May 2010 04:39:14 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:41974 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752739Ab0EMIjL (ORCPT ); Thu, 13 May 2010 04:39:11 -0400 Date: Thu, 13 May 2010 10:38:18 +0200 From: Ingo Molnar To: Lin Ming Cc: greg@kroah.com, Peter Zijlstra , Corey Ashford , Frederic Weisbecker , "eranian@gmail.com" , "Gary.Mohr@Bull.com" , "arjan@linux.intel.com" , "Zhang, Yanmin" , Paul Mackerras , "David S. Miller" , Russell King , Paul Mundt , lkml , Arnaldo Carvalho de Melo , Will Deacon , Maynard Johnson , Carl Love Subject: Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs Message-ID: <20100513083818.GA21924@elte.hu> References: <20100510115344.GA11238@elte.hu> <4BE8931C.9070106@linux.vnet.ibm.com> <1273560419.5605.3426.camel@twins> <20100511072127.GB10421@elte.hu> <1273566031.30322.31.camel@minggr.sh.intel.com> <1273567815.5605.3491.camel@twins> <1273568620.30322.42.camel@minggr.sh.intel.com> <1273569154.5605.3499.camel@twins> <20100511091833.GB18869@elte.hu> <1273739333.30322.119.camel@minggr.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273739333.30322.119.camel@minggr.sh.intel.com> User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Lin Ming wrote: > On Tue, 2010-05-11 at 17:18 +0800, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > > > The new PMUs will use a dynamic range that starts at PERF_TYPE_MAX. > > > > I dont think we should use a dynamic range of event sources - it's a > > completely useless indirection that has no meaning to humans. > > > > As far as machine interfaces go a much cleaner approach would be to allow an > > open fd to a sysfs file to be passed to sys_perf_event_open() - this would > > identify the event source. This needs a small extension of the ABI but we > > could thus get rid of the 'type' enumeration altogether and express _all_ > > event sources via fds to sysfs files. > > I still don't understand this sys_fd -> pmu lookup, would you please > explain it more detail? > > struct pmu { > kobject kobj; > ... > }; > > What I can imagine is, > > 1. In userspace, sys_fd = > open("/sys/devices/system/cpu/event_source", ..), then sys_fd is passed > to sys_perf_event_open() Yes, open() an event_source - or rather an event itself. For raw events there has to be a separate event entry that can be opened. I.e. we'd have a layout like: /sys/devices/system/cpu/events/cycles/id /sys/devices/system/cpu/events/instructions/id /sys/devices/system/cpu/events/raw/id By making each event category a directory we gain the flexibility of integrating tracepoints as well, for example: /sys/kernel/sched/events/wakeup/id /sys/kernel/sched/events/wakeup/format Where 'format' describes the event record layout: # cat /debug/tracing/events/sched/sched_wakeup/format name: sched_wakeup ID: 59 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_lock_depth; offset:8; size:4; signed:1; field:char comm[TASK_COMM_LEN]; offset:12; size:16; signed:1; field:pid_t pid; offset:28; size:4; signed:1; field:int prio; offset:32; size:4; signed:1; field:int success; offset:36; size:4; signed:1; field:int target_cpu; offset:40; size:4; signed:1; print fmt: "comm=%s pid=%d prio=%d success=%d target_cpu=%03d", REC->comm, REC->pid, REC->prio, REC->success, REC->target_cpu > 2. In kernel, sys_file = > > 3. kobject = > > 4. pmu = container_of(kobject, struct pmu, kobj) > > If my understanding is correct, then step 3 above seems strange. It's > not the typical usage of sys file. I dont think it's stange - we demux from the generic sysfs object to the more specific perf events related object. This is similar how driver specific sysfs functionality does the demux as well. Ingo