perf_event_open/perf_event_open02.c: cleanup
According to perf_event_open()'s manpage, the official way of knowing
if perf_event_open() support is enabled is checking for the existence
of the file /proc/sys/kernel/perf_event_paranoid, so add this check.
According to this perf_event_open API description, rewrite this test.
int perf_event_open(struct perf_event_attr *attr,
pid_t pid, int cpu, int group_fd,
unsigned long flags);
Performance_counter02 needs to know the number of max available hardware
counters on PMU, we use the below methods to get this number.
Accordind to perf_event_open()'s manpage, once a perf_event_open() fd has
been opened, the values of the events can be read from the file descriptor.
The values are specified by the read_format field in the perf_event_attr
structure at open time. Here is the layout of the data returned by a read:
If PERF_FORMAT_GROUP was not specified:
struct read_format {
u64 value; /* The value of the event */
u64 time_enabled; /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
u64 time_running; /* if PERF_FORMAT_TOTAL_TIME_RUNNING */
u64 id; /* if PERF_FORMAT_ID */
};
Normally time_enabled and time_running are the same value. But if more events are
started than available counter slots on the PMU, then multiplexing happens and
events run only part of the time. Time_enabled and time_running's values will be
different. In this case the time_enabled and time_running values can be used to
scale an estimated value for the count. So if time_enabled and time_running are
not equal, we can think that PMU hardware counters multiplexing happens and the
number of the opened events are the number of max available hardware counters.
Some cleanup.
Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
2 files changed