Re: [RFC][PATCH v1 02/15] perf: export generic hardware events via sysfs

[Lin Ming <ming.m.lin@intel.com>]

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
>