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
|-- LLC-load-misses
| |-- config
| `-- type
|-- branch-misses
| |-- config
| `-- type
|-- branches
| |-- config
| `-- type
|-- bus-cycles
| |-- config
| `-- type
|-- cache-misses
| |-- config
| `-- type
|-- cache-references
| |-- config
| `-- type
|-- cycles
| |-- config
| `-- type
|-- dTLB-load-misses
| |-- config
| `-- type
|-- dTLB-store-misses
| |-- config
| `-- type
|-- iTLB-load-misses
| |-- config
| `-- type
|-- iTLB-load-refs
| |-- config
| `-- type
`-- instructions
|-- config
`-- type
---
arch/x86/kernel/cpu/perf_event.c | 55 +++++++++++++++++++++++++++++++++++
include/linux/perf_event.h | 7 ++++-
kernel/perf_event.c | 59 ++++++++++++++++++++++++++++++++++++++
3 files changed, 120 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 2712414..2e66c35 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1328,6 +1328,59 @@ static void __init pmu_check_apic(void)
pr_info("no hardware sampling interrupt available.\n");
}
+static void export_events(struct kobject *cpu_kobj)
+{
+ struct kobject *events_kobj;
+ int type, op, i;
+ int cache_id;
+ int err = 0;
+
+ if (!cpu_kobj)
+ return;
+
+ events_kobj = perf_sys_create_events_dir(cpu_kobj);
+ if (!events_kobj)
+ return;
+
+ for (i = PERF_COUNT_HW_CPU_CYCLES; i < PERF_COUNT_HW_MAX; i++) {
+ perf_sys_add_event(events_kobj, perf_hw_event_name(i),
+ i, PERF_TYPE_HARDWARE);
+ }
+
+ for (type = 0; type < PERF_COUNT_HW_CACHE_MAX; type++) {
+ for (op = 0; op < PERF_COUNT_HW_CACHE_OP_MAX; op++) {
+ for (i = 0; i < PERF_COUNT_HW_CACHE_RESULT_MAX; i++) {
+
+ cache_id = hw_cache_event_ids[type][op][i];
+ if (cache_id <= 0)
+ continue;
+
+ err = perf_sys_add_event(events_kobj,
+ perf_hw_cache_event_name(type, op, i),
+ cache_id, PERF_TYPE_HW_CACHE);
+ if (err)
+ break;
+ }
+ }
+ }
+}
+
+static void x86_pmu_export_events(void)
+{
+ struct sys_device *cpu_dev;
+ int cpu;
+
+ /* /sys/devices/system/cpu/cpu0...cpuN/events/ */
+
+ for_each_online_cpu(cpu) {
+ cpu_dev = get_cpu_sysdev(cpu);
+ if (!cpu_dev)
+ break;
+
+ export_events(&cpu_dev->kobj);
+ }
+}
+
void __init init_hw_perf_events(void)
{
struct event_constraint *c;
@@ -1600,6 +1653,8 @@ static struct pmu pmu = {
.start_txn = x86_pmu_start_txn,
.cancel_txn = x86_pmu_cancel_txn,
.commit_txn = x86_pmu_commit_txn,
+
+ .export_events = x86_pmu_export_events,
};
/*
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 5e9f5c6..fb2ec23 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -630,6 +630,8 @@ struct pmu {
* for each successfull ->add() during the transaction.
*/
void (*cancel_txn) (struct pmu *pmu); /* optional */
+
+ void (*export_events) (void);
};
/**
@@ -1060,6 +1062,8 @@ extern void perf_event_disable(struct perf_event *event);
extern struct kobject *perf_sys_create_events_dir(struct kobject *parent);
extern int perf_sys_add_event(struct kobject *parent, char *name, u64 config, int type);
+extern char *perf_hw_event_name(int id);
+extern char *perf_hw_cache_event_name(u8 type, u8 op, u8 result);
#else
static inline void
perf_event_task_sched_in(struct task_struct *task) { }
@@ -1100,11 +1104,12 @@ static inline int perf_sys_add_event(struct kobject *parent, char *name, u64 con
{
return 0;
}
-
static inline struct kobject *perf_sys_create_events_dir(struct kobject *parent)
{
return NULL;
}
+static inline char *perf_hw_event_name(int id) { return NULL; }
+static inline char *perf_hw_cache_event_name(u8 type, u8 op, u8 result) { return NULL; }
#endif
#define perf_output_put(handle, x) \
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index ae95633..1f51ab9 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -5884,6 +5884,16 @@ static struct attribute_group perfclass_attr_group = {
static int __init perf_event_sysfs_init(void)
{
+ struct pmu *pmu = NULL;
+ int idx;
+
+ idx = srcu_read_lock(&pmus_srcu);
+ list_for_each_entry_rcu(pmu, &pmus, entry) {
+ if (pmu->export_events)
+ pmu->export_events();
+ }
+ srcu_read_unlock(&pmus_srcu, idx);
+
return sysfs_create_group(&cpu_sysdev_class.kset.kobj,
&perfclass_attr_group);
}
@@ -5992,3 +6002,52 @@ int perf_sys_add_event(struct kobject *parent, char *name, u64 config, int type)
return 0;
}
+
+static char *hw_event_names[] = {
+ "cycles",
+ "instructions",
+ "cache-references",
+ "cache-misses",
+ "branches",
+ "branch-misses",
+ "bus-cycles",
+};
+
+static char *hw_cache[] = {
+ "L1-dcache",
+ "L1-icache",
+ "LLC",
+ "dTLB",
+ "iTLB",
+ "branch",
+};
+
+static char *hw_cache_op[] = {
+ "load",
+ "store",
+ "prefetch",
+};
+
+static char *hw_cache_result[] = {
+ "refs",
+ "misses",
+};
+
+char *perf_hw_event_name(int id)
+{
+ if (id >= ARRAY_SIZE(hw_event_names))
+ return NULL;
+
+ return hw_event_names[id];
+}
+
+char *perf_hw_cache_event_name(u8 cache_type, u8 cache_op, u8 cache_result)
+{
+ static char name[50];
+
+ sprintf(name, "%s-%s-%s", hw_cache[cache_type],
+ hw_cache_op[cache_op],
+ hw_cache_result[cache_result]);
+
+ return name;
+}
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.
(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
--
Advanced Micro Devices, Inc.
Operating System Research Center
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
>
On 26.07.10 22:18:23, Lin Ming wrote:
> > > /sys/devices/system/cpu/cpu0/events
> > > |-- L1-dcache-load-misses
> > > | |-- config
> > > | `-- type
vs.
> > |-- L1-dcache-load-misses ===> event name
> > | `-- id ===> event id
> > This is very simple and flexible and solves the original problem too.
>
> Yeah, this is flexible. I'll think about this closely.
The thing is, if you start introducing the config/type i/f, we will
stick with it for a long time. I want to avoid this from the
beginning.
Using an id only would work with your current implementation too, you
only need to maintain an id -> config/type mapping, maybe in some
private data section, without exporting it to userspace.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
On 07/27/2010 01:27 AM, Robert Richter wrote:
> On 26.07.10 22:18:23, Lin Ming wrote:
>
>>>> /sys/devices/system/cpu/cpu0/events
>>>> |-- L1-dcache-load-misses
>>>> | |-- config
>>>> | `-- type
>
> vs.
>
>>> |-- L1-dcache-load-misses ===> event name
>>> | `-- id ===> event id
>
>>> This is very simple and flexible and solves the original problem too.
>>
>> Yeah, this is flexible. I'll think about this closely.
>
> The thing is, if you start introducing the config/type i/f, we will
> stick with it for a long time. I want to avoid this from the
> beginning.
>
> Using an id only would work with your current implementation too, you
> only need to maintain an id -> config/type mapping, maybe in some
> private data section, without exporting it to userspace.
Now that I understand that the sysfs id essentially points to a kernel
data structure, I like this idea a lot. Before I was thinking that you
were trying to place a lot of info into the id itself.
The only downside I see, and maybe it's a very minor one, is that you'll
no longer have the ability to specify an event without specifying a
sysfs path... there's no other mechanism.
- Corey
On 27.07.10 13:51:55, Corey Ashford wrote:
> On 07/27/2010 01:27 AM, Robert Richter wrote:
> > On 26.07.10 22:18:23, Lin Ming wrote:
> >
> >>>> /sys/devices/system/cpu/cpu0/events
> >>>> |-- L1-dcache-load-misses
> >>>> | |-- config
> >>>> | `-- type
> >
> > vs.
> >
> >>> |-- L1-dcache-load-misses ===> event name
> >>> | `-- id ===> event id
> >
> >>> This is very simple and flexible and solves the original problem too.
> >>
> >> Yeah, this is flexible. I'll think about this closely.
> >
> > The thing is, if you start introducing the config/type i/f, we will
> > stick with it for a long time. I want to avoid this from the
> > beginning.
> >
> > Using an id only would work with your current implementation too, you
> > only need to maintain an id -> config/type mapping, maybe in some
> > private data section, without exporting it to userspace.
>
> Now that I understand that the sysfs id essentially points to a kernel
> data structure, I like this idea a lot. Before I was thinking that you
> were trying to place a lot of info into the id itself.
>
> The only downside I see, and maybe it's a very minor one, is that you'll
> no longer have the ability to specify an event without specifying a
> sysfs path... there's no other mechanism.
Right, the id is generated dynamically, it could be an incremented u64
value, a pointer to a kernel structure or something else. Its
implementation could even change from kernel to kernel without
breaking the i/f.
Note also, that you will still be able to setup current events using
the traditional way of filling in the syscall structure. Nothing will
change for this.
But yes, a new event could only support a sysfs id setup. And then,
you need sysfs. But you could also implement a non-sysfs setup in
addition.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
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;
> ...
>
With your proposal, seems that all the attributes needed to set up an
event is still specified by user, instead of reading them from sysfs.
For example, how to trace sda block_bio_backmerge event? Did you still
need "--filter" option?
perf record -e /sys/.../sda/events/block_bio_backmerge --filter "dev==0"
Why not show the "filter" in sysfs? like below
/sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/events
|-- block_bio_backmerge
| |-- config
| |-- type
| |-- filter
Then userspace tool can read the attributes and set up the event
automatically.
But the difficulty is different type of events have different set of
attributes, that we need a unify way to let userspace tool know what
attributes are available.
So my original idea was to export as many attributes as possible for
each event.
Thanks,
Lin Ming
> 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.
>
> (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
>