Messages in this thread | | | Subject | Re: [RFC][PATCH v1 02/15] perf: export generic hardware events via sysfs | From | Lin Ming <> | Date | Tue, 27 Jul 2010 10:18:23 +0800 |
| |
On Fri, 2010-07-23 at 18:44 +0800, Robert Richter wrote: > On 22.07.10 07:12:22, Lin Ming wrote: > > Generic hardware events are exported under > > /sys/devices/system/cpu/cpu0...N/events, for example > > > > /sys/devices/system/cpu/cpu0/events > > |-- L1-dcache-load-misses > > | |-- config > > | `-- type > > The sysfs approach came up as a solution to connect to dynamically > added pmus of various kind of hardware. The current mechanism using > config/type style did not fit anymore because we would have to > continuously extend the syscall i/f by new flags and attributes for > every new event. So, the problem is not which config and type > parameters to use for creating an event, we need a _different_ way for > this. > > The config and type value you expose to sysfs are only used for > setting up the syscall. So, I want to bring up my idea again here that > I posted some days ago to lkml, using a unique sysfs id to specify > event classes. > > Simply export an id (an u64), like: > > |-- L1-dcache-load-misses ===> event name > | `-- id ===> event id > > ... and then extend the syscall to enable an event by its sysfs id: > > memset(&attr, 0, sizeof(attr)); > attr.type = PERF_TYPE_SYSFS; > attr.sysfs_id = sysfs_id; > attr.sample_type = PERF_SAMPLE_CPU | PERF_SAMPLE_RAW; > attr.config = config; > ... > > The config value can then be (re-)used to setup this _specific_ event > individually. > > The kernel knows the id and is able to route the event request > directly to that particular pmu, something like: > > struct event_kobject { > struct kobject *kobj; > u64 id; > struct pmu *pmu; > struct event_kobject *next; > }; > > struct event_kobject *eclass; > > eclass = find_event_kobject(id); > eclass->pmu->event_init(event); > ... > > This is very simple and flexible and solves the original problem too.
Yeah, this is flexible. I'll think about this closely.
Thanks, Lin Ming
> > (reposting my previous mail:) > > You still need knowledge of what the event is measuring and how it is > set up or configured. Maybe the configuration may left blank if the > event can be setup without it. But with this approach you can get file > descriptors for every event a user may be interested in simply by > looking into sysfs. > > For example, I was thinking of perfctr events vs. ibs events. The cpu > could setup something like: > > /sys/devices/system/cpu/cpu0...cpuN/events/perfctr/id > /sys/devices/system/cpu/cpu0...cpuN/events/ibs_op/id > > Both events are setup with one 64 bit config value that is basically > the event's configuration msr (x86 perfctr or AMD IBS). These are > definded in the hardware specifications. Its formats differ. You could > then open the event file descriptor using the sysfs id and use the > config value to customize the event. You don't have a complicated > setup or implementation to detect which kind of event you want to use > as the id indicates the type of event. > > Actually, we could setup e.g. also trace events with this mechanism. > > -Robert >
| |