lkml.org 
[lkml]   [2010]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH v1 02/15] perf: export generic hardware events via sysfs
From
Date
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
>




\
 
 \ /
  Last update: 2010-07-27 04:21    [W:0.059 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site