bperf has a nice ability to share PMUs, but it still does not support
inherit events during fork(), resulting in some deviations in its stat
results compared with perf.
perf stat result:
$ ./perf stat -e cycles,instructions -- ./perf test -w sqrtloop
Performance counter stats for './perf test -w sqrtloop':
2,316,038,116 cycles
2,859,350,725 instructions
1.009603637 seconds time elapsed
1.004196000 seconds user
0.003950000 seconds sys
bperf stat result:
$ ./perf stat --bpf-counters -e cycles,instructions -- \
./perf test -w sqrtloop
Performance counter stats for './perf test -w sqrtloop':
18,762,093 cycles
23,487,766 instructions
1.008913769 seconds time elapsed
1.003248000 seconds user
0.004069000 seconds sys
In order to support event inheritance, two new bpf programs are added
to monitor the fork and exit of tasks respectively. When a task is
created, add it to the filter map to enable counting, and reuse the
`accum_key` of its parent task to count together with the parent task.
When a task exits, remove it from the filter map to disable counting.
After support:
$ ./perf stat --bpf-counters -e cycles,instructions -- \
./perf test -w sqrtloop
Performance counter stats for './perf test -w sqrtloop':
2,316,252,189 cycles
2,859,946,547 instructions
1.009422314 seconds time elapsed
1.003597000 seconds user
0.004270000 seconds sys
Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
---
tools/perf/util/bpf_counter.c | 32 +++++--
tools/perf/util/bpf_skel/bperf_follower.bpf.c | 87 +++++++++++++++++--
tools/perf/util/bpf_skel/bperf_u.h | 5 ++
3 files changed, 111 insertions(+), 13 deletions(-)
diff --git a/tools/perf/util/bpf_counter.c b/tools/perf/util/bpf_counter.c
index 7a8af60e0f51..94aa46f50052 100644
--- a/tools/perf/util/bpf_counter.c
+++ b/tools/perf/util/bpf_counter.c
@@ -394,6 +394,7 @@ static int bperf_check_target(struct evsel *evsel,
}
static struct perf_cpu_map *all_cpu_map;
+static __u32 filter_entry_cnt;
static int bperf_reload_leader_program(struct evsel *evsel, int attr_map_fd,
struct perf_event_attr_map_entry *entry)
@@ -444,12 +445,31 @@ static int bperf_reload_leader_program(struct evsel *evsel, int attr_map_fd,
return err;
}
+/* Attach programs on demand according to filter types to reduce overhead */
+static int bperf_attach_follower_program(struct bperf_follower_bpf *skel,
+ enum bperf_filter_type filter_type)
+{
+ struct bpf_link *link;
+ int err = 0;
+
+ if (filter_type == BPERF_FILTER_PID ||
+ filter_type == BPERF_FILTER_TGID)
+ err = bperf_follower_bpf__attach(skel);
+ else {
+ link = bpf_program__attach(skel->progs.fexit_XXX);
+ if (IS_ERR(link))
+ err = PTR_ERR(link);
+ }
+
+ return err;
+}
+
static int bperf__load(struct evsel *evsel, struct target *target)
{
struct perf_event_attr_map_entry entry = {0xffffffff, 0xffffffff};
int attr_map_fd, diff_map_fd = -1, err;
enum bperf_filter_type filter_type;
- __u32 filter_entry_cnt, i;
+ __u32 i;
if (bperf_check_target(evsel, target, &filter_type, &filter_entry_cnt))
return -1;
@@ -529,9 +549,6 @@ static int bperf__load(struct evsel *evsel, struct target *target)
/* set up reading map */
bpf_map__set_max_entries(evsel->follower_skel->maps.accum_readings,
filter_entry_cnt);
- /* set up follower filter based on target */
- bpf_map__set_max_entries(evsel->follower_skel->maps.filter,
- filter_entry_cnt);
err = bperf_follower_bpf__load(evsel->follower_skel);
if (err) {
pr_err("Failed to load follower skeleton\n");
@@ -543,6 +560,7 @@ static int bperf__load(struct evsel *evsel, struct target *target)
for (i = 0; i < filter_entry_cnt; i++) {
int filter_map_fd;
__u32 key;
+ struct bperf_filter_value fval = { i, 0 };
if (filter_type == BPERF_FILTER_PID ||
filter_type == BPERF_FILTER_TGID)
@@ -553,12 +571,12 @@ static int bperf__load(struct evsel *evsel, struct target *target)
break;
filter_map_fd = bpf_map__fd(evsel->follower_skel->maps.filter);
- bpf_map_update_elem(filter_map_fd, &key, &i, BPF_ANY);
+ bpf_map_update_elem(filter_map_fd, &key, &fval, BPF_ANY);
}
evsel->follower_skel->bss->type = filter_type;
- err = bperf_follower_bpf__attach(evsel->follower_skel);
+ err = bperf_attach_follower_program(evsel->follower_skel, filter_type);
out:
if (err && evsel->bperf_leader_link_fd >= 0)
@@ -623,7 +641,7 @@ static int bperf__read(struct evsel *evsel)
bperf_sync_counters(evsel);
reading_map_fd = bpf_map__fd(skel->maps.accum_readings);
- for (i = 0; i < bpf_map__max_entries(skel->maps.accum_readings); i++) {
+ for (i = 0; i < filter_entry_cnt; i++) {
struct perf_cpu entry;
__u32 cpu;
diff --git a/tools/perf/util/bpf_skel/bperf_follower.bpf.c b/tools/perf/util/bpf_skel/bperf_follower.bpf.c
index f193998530d4..e804b2a9d0a6 100644
--- a/tools/perf/util/bpf_skel/bperf_follower.bpf.c
+++ b/tools/perf/util/bpf_skel/bperf_follower.bpf.c
@@ -5,6 +5,8 @@
#include <bpf/bpf_tracing.h>
#include "bperf_u.h"
+#define MAX_ENTRIES 102400
+
struct {
__uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
__uint(key_size, sizeof(__u32));
@@ -22,7 +24,9 @@ struct {
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(key_size, sizeof(__u32));
- __uint(value_size, sizeof(__u32));
+ __uint(value_size, sizeof(struct bperf_filter_value));
+ __uint(max_entries, MAX_ENTRIES);
+ __uint(map_flags, BPF_F_NO_PREALLOC);
} filter SEC(".maps");
enum bperf_filter_type type = 0;
@@ -33,14 +37,15 @@ int BPF_PROG(fexit_XXX)
{
struct bpf_perf_event_value *diff_val, *accum_val;
__u32 filter_key, zero = 0;
- __u32 *accum_key;
+ __u32 accum_key;
+ struct bperf_filter_value *fval;
if (!enabled)
return 0;
switch (type) {
case BPERF_FILTER_GLOBAL:
- accum_key = &zero;
+ accum_key = zero;
goto do_add;
case BPERF_FILTER_CPU:
filter_key = bpf_get_smp_processor_id();
@@ -55,16 +60,20 @@ int BPF_PROG(fexit_XXX)
return 0;
}
- accum_key = bpf_map_lookup_elem(&filter, &filter_key);
- if (!accum_key)
+ fval = bpf_map_lookup_elem(&filter, &filter_key);
+ if (!fval)
return 0;
+ accum_key = fval->accum_key;
+ if (fval->exited)
+ bpf_map_delete_elem(&filter, &filter_key);
+
do_add:
diff_val = bpf_map_lookup_elem(&diff_readings, &zero);
if (!diff_val)
return 0;
- accum_val = bpf_map_lookup_elem(&accum_readings, accum_key);
+ accum_val = bpf_map_lookup_elem(&accum_readings, &accum_key);
if (!accum_val)
return 0;
@@ -75,4 +84,70 @@ int BPF_PROG(fexit_XXX)
return 0;
}
+/* The program is only used for PID or TGID filter types. */
+SEC("tp_btf/task_newtask")
+int BPF_PROG(on_newtask, struct task_struct *task, __u64 clone_flags)
+{
+ __u32 parent_key, child_key;
+ struct bperf_filter_value *parent_fval;
+ struct bperf_filter_value child_fval = { 0 };
+
+ if (!enabled)
+ return 0;
+
+ switch (type) {
+ case BPERF_FILTER_PID:
+ parent_key = bpf_get_current_pid_tgid() & 0xffffffff;
+ child_key = task->pid;
+ break;
+ case BPERF_FILTER_TGID:
+ parent_key = bpf_get_current_pid_tgid() >> 32;
+ child_key = task->tgid;
+ if (child_key == parent_key)
+ return 0;
+ break;
+ default:
+ return 0;
+ }
+
+ /* Check if the current task is one of the target tasks to be counted */
+ parent_fval = bpf_map_lookup_elem(&filter, &parent_key);
+ if (!parent_fval)
+ return 0;
+
+ /* Start counting for the new task by adding it into filter map,
+ * inherit the accum key of its parent task so that they can be
+ * counted together.
+ */
+ child_fval.accum_key = parent_fval->accum_key;
+ child_fval.exited = 0;
+ bpf_map_update_elem(&filter, &child_key, &child_fval, BPF_NOEXIST);
+
+ return 0;
+}
+
+/* The program is only used for PID or TGID filter types. */
+SEC("tp_btf/sched_process_exit")
+int BPF_PROG(on_exittask, struct task_struct *task)
+{
+ __u32 pid;
+ struct bperf_filter_value *fval;
+
+ if (!enabled)
+ return 0;
+
+ /* Stop counting for this task by removing it from filter map.
+ * For TGID type, if the pid can be found in the map, it means that
+ * this pid belongs to the leader task. After the task exits, the
+ * tgid of its child tasks (if any) will be 1, so the pid can be
+ * safely removed.
+ */
+ pid = task->pid;
+ fval = bpf_map_lookup_elem(&filter, &pid);
+ if (fval)
+ fval->exited = 1;
+
+ return 0;
+}
+
char LICENSE[] SEC("license") = "Dual BSD/GPL";
diff --git a/tools/perf/util/bpf_skel/bperf_u.h b/tools/perf/util/bpf_skel/bperf_u.h
index 1ce0c2c905c1..4a4a753980be 100644
--- a/tools/perf/util/bpf_skel/bperf_u.h
+++ b/tools/perf/util/bpf_skel/bperf_u.h
@@ -11,4 +11,9 @@ enum bperf_filter_type {
BPERF_FILTER_TGID,
};
+struct bperf_filter_value {
+ __u32 accum_key;
+ __u8 exited;
+};
+
#endif /* __BPERF_STAT_U_H */
--
2.34.1On Sun, Sep 15, 2024 at 6:53 PM Tengda Wu <wutengda@huaweicloud.com> wrote:
>
> bperf has a nice ability to share PMUs, but it still does not support
> inherit events during fork(), resulting in some deviations in its stat
> results compared with perf.
>
> perf stat result:
> $ ./perf stat -e cycles,instructions -- ./perf test -w sqrtloop
>
> Performance counter stats for './perf test -w sqrtloop':
>
> 2,316,038,116 cycles
> 2,859,350,725 instructions
>
> 1.009603637 seconds time elapsed
>
> 1.004196000 seconds user
> 0.003950000 seconds sys
>
> bperf stat result:
> $ ./perf stat --bpf-counters -e cycles,instructions -- \
> ./perf test -w sqrtloop
>
> Performance counter stats for './perf test -w sqrtloop':
>
> 18,762,093 cycles
> 23,487,766 instructions
>
> 1.008913769 seconds time elapsed
>
> 1.003248000 seconds user
> 0.004069000 seconds sys
>
> In order to support event inheritance, two new bpf programs are added
> to monitor the fork and exit of tasks respectively. When a task is
> created, add it to the filter map to enable counting, and reuse the
> `accum_key` of its parent task to count together with the parent task.
> When a task exits, remove it from the filter map to disable counting.
>
> After support:
> $ ./perf stat --bpf-counters -e cycles,instructions -- \
> ./perf test -w sqrtloop
>
> Performance counter stats for './perf test -w sqrtloop':
>
> 2,316,252,189 cycles
> 2,859,946,547 instructions
>
> 1.009422314 seconds time elapsed
>
> 1.003597000 seconds user
> 0.004270000 seconds sys
>
> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
The solution looks good to me. Question on the UI: do we always
want the inherit behavior from PID and TGID monitoring? If not,
maybe we should add a flag for it. (I think we do need the flag).
One nitpick below.
Thanks,
Song
[...]
>
> +struct bperf_filter_value {
> + __u32 accum_key;
> + __u8 exited;
> +};
nit:
Can we use a special value of accum_key to replace exited==1
case?
> +
> #endif /* __BPERF_STAT_U_H */
> --
> 2.34.1
>
On Wed, Oct 09, 2024 at 10:18:44AM -0700, Song Liu wrote:
> On Sun, Sep 15, 2024 at 6:53 PM Tengda Wu <wutengda@huaweicloud.com> wrote:
> >
> > bperf has a nice ability to share PMUs, but it still does not support
> > inherit events during fork(), resulting in some deviations in its stat
> > results compared with perf.
> >
> > perf stat result:
> > $ ./perf stat -e cycles,instructions -- ./perf test -w sqrtloop
> >
> > Performance counter stats for './perf test -w sqrtloop':
> >
> > 2,316,038,116 cycles
> > 2,859,350,725 instructions
> >
> > 1.009603637 seconds time elapsed
> >
> > 1.004196000 seconds user
> > 0.003950000 seconds sys
> >
> > bperf stat result:
> > $ ./perf stat --bpf-counters -e cycles,instructions -- \
> > ./perf test -w sqrtloop
> >
> > Performance counter stats for './perf test -w sqrtloop':
> >
> > 18,762,093 cycles
> > 23,487,766 instructions
> >
> > 1.008913769 seconds time elapsed
> >
> > 1.003248000 seconds user
> > 0.004069000 seconds sys
> >
> > In order to support event inheritance, two new bpf programs are added
> > to monitor the fork and exit of tasks respectively. When a task is
> > created, add it to the filter map to enable counting, and reuse the
> > `accum_key` of its parent task to count together with the parent task.
> > When a task exits, remove it from the filter map to disable counting.
> >
> > After support:
> > $ ./perf stat --bpf-counters -e cycles,instructions -- \
> > ./perf test -w sqrtloop
> >
> > Performance counter stats for './perf test -w sqrtloop':
> >
> > 2,316,252,189 cycles
> > 2,859,946,547 instructions
> >
> > 1.009422314 seconds time elapsed
> >
> > 1.003597000 seconds user
> > 0.004270000 seconds sys
> >
> > Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
>
> The solution looks good to me. Question on the UI: do we always
> want the inherit behavior from PID and TGID monitoring? If not,
> maybe we should add a flag for it. (I think we do need the flag).
I think it should depend on the value of attr.inherit. Maybe we can
disable the autoload for !inherit.
>
> One nitpick below.
>
> Thanks,
> Song
>
> [...]
> >
> > +struct bperf_filter_value {
> > + __u32 accum_key;
> > + __u8 exited;
> > +};
> nit:
> Can we use a special value of accum_key to replace exited==1
> case?
I'm not sure. I guess it still needs to use the accum_key to save the
final value when exited = 1.
Thanks,
Namhyung
>
> > +
> > #endif /* __BPERF_STAT_U_H */
> > --
> > 2.34.1
> >
On 2024/10/10 8:31, Namhyung Kim wrote:
> On Wed, Oct 09, 2024 at 10:18:44AM -0700, Song Liu wrote:
>> On Sun, Sep 15, 2024 at 6:53 PM Tengda Wu <wutengda@huaweicloud.com> wrote:
>>>
>>> bperf has a nice ability to share PMUs, but it still does not support
>>> inherit events during fork(), resulting in some deviations in its stat
>>> results compared with perf.
>>>
>>> perf stat result:
>>> $ ./perf stat -e cycles,instructions -- ./perf test -w sqrtloop
>>>
>>> Performance counter stats for './perf test -w sqrtloop':
>>>
>>> 2,316,038,116 cycles
>>> 2,859,350,725 instructions
>>>
>>> 1.009603637 seconds time elapsed
>>>
>>> 1.004196000 seconds user
>>> 0.003950000 seconds sys
>>>
>>> bperf stat result:
>>> $ ./perf stat --bpf-counters -e cycles,instructions -- \
>>> ./perf test -w sqrtloop
>>>
>>> Performance counter stats for './perf test -w sqrtloop':
>>>
>>> 18,762,093 cycles
>>> 23,487,766 instructions
>>>
>>> 1.008913769 seconds time elapsed
>>>
>>> 1.003248000 seconds user
>>> 0.004069000 seconds sys
>>>
>>> In order to support event inheritance, two new bpf programs are added
>>> to monitor the fork and exit of tasks respectively. When a task is
>>> created, add it to the filter map to enable counting, and reuse the
>>> `accum_key` of its parent task to count together with the parent task.
>>> When a task exits, remove it from the filter map to disable counting.
>>>
>>> After support:
>>> $ ./perf stat --bpf-counters -e cycles,instructions -- \
>>> ./perf test -w sqrtloop
>>>
>>> Performance counter stats for './perf test -w sqrtloop':
>>>
>>> 2,316,252,189 cycles
>>> 2,859,946,547 instructions
>>>
>>> 1.009422314 seconds time elapsed
>>>
>>> 1.003597000 seconds user
>>> 0.004270000 seconds sys
>>>
>>> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
>>
>> The solution looks good to me. Question on the UI: do we always
>> want the inherit behavior from PID and TGID monitoring? If not,
>> maybe we should add a flag for it. (I think we do need the flag).
>
> I think it should depend on the value of attr.inherit. Maybe we can
> disable the autoload for !inherit.
>
Got it. The attr.inherit flag(related to --no-inherit in perf command)
is suitable for controlling inherit behavior. I will fix it. Thanks!
>>
>> One nitpick below.
>>
>> Thanks,
>> Song
>>
>> [...]
>>>
>>> +struct bperf_filter_value {
>>> + __u32 accum_key;
>>> + __u8 exited;
>>> +};
>> nit:
>> Can we use a special value of accum_key to replace exited==1
>> case?
>
> I'm not sure. I guess it still needs to use the accum_key to save the
> final value when exited = 1.
In theory, it is possible. The accum_key is currently only used to index value
in accum_readings map, so if the task is not being counted, the accum_key can
be set to an special value.
Due to accum_key is of u32 type, there are two special values to choose from: 0
or max_entries+1. I think the latter, max_entries+1, may be more suitable because
it can avoid memory waste in the accum_readings map and does not require too
many changes to bpf_counter.
Thanks for your kindly review!
Tengda
>
> Thanks,
> Namhyung
>
>>
>>> +
>>> #endif /* __BPERF_STAT_U_H */
>>> --
>>> 2.34.1
>>>
On 2024/10/10 12:53, Tengda Wu wrote:
>
>
> On 2024/10/10 8:31, Namhyung Kim wrote:
>> On Wed, Oct 09, 2024 at 10:18:44AM -0700, Song Liu wrote:
>>> On Sun, Sep 15, 2024 at 6:53 PM Tengda Wu <wutengda@huaweicloud.com> wrote:
>>>>
>>>> bperf has a nice ability to share PMUs, but it still does not support
>>>> inherit events during fork(), resulting in some deviations in its stat
>>>> results compared with perf.
>>>>
>>>> perf stat result:
>>>> $ ./perf stat -e cycles,instructions -- ./perf test -w sqrtloop
>>>>
>>>> Performance counter stats for './perf test -w sqrtloop':
>>>>
>>>> 2,316,038,116 cycles
>>>> 2,859,350,725 instructions
>>>>
>>>> 1.009603637 seconds time elapsed
>>>>
>>>> 1.004196000 seconds user
>>>> 0.003950000 seconds sys
>>>>
>>>> bperf stat result:
>>>> $ ./perf stat --bpf-counters -e cycles,instructions -- \
>>>> ./perf test -w sqrtloop
>>>>
>>>> Performance counter stats for './perf test -w sqrtloop':
>>>>
>>>> 18,762,093 cycles
>>>> 23,487,766 instructions
>>>>
>>>> 1.008913769 seconds time elapsed
>>>>
>>>> 1.003248000 seconds user
>>>> 0.004069000 seconds sys
>>>>
>>>> In order to support event inheritance, two new bpf programs are added
>>>> to monitor the fork and exit of tasks respectively. When a task is
>>>> created, add it to the filter map to enable counting, and reuse the
>>>> `accum_key` of its parent task to count together with the parent task.
>>>> When a task exits, remove it from the filter map to disable counting.
>>>>
>>>> After support:
>>>> $ ./perf stat --bpf-counters -e cycles,instructions -- \
>>>> ./perf test -w sqrtloop
>>>>
>>>> Performance counter stats for './perf test -w sqrtloop':
>>>>
>>>> 2,316,252,189 cycles
>>>> 2,859,946,547 instructions
>>>>
>>>> 1.009422314 seconds time elapsed
>>>>
>>>> 1.003597000 seconds user
>>>> 0.004270000 seconds sys
>>>>
>>>> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
>>>
>>> The solution looks good to me. Question on the UI: do we always
>>> want the inherit behavior from PID and TGID monitoring? If not,
>>> maybe we should add a flag for it. (I think we do need the flag).
>>
>> I think it should depend on the value of attr.inherit. Maybe we can
>> disable the autoload for !inherit.
>>
>
> Got it. The attr.inherit flag(related to --no-inherit in perf command)
> is suitable for controlling inherit behavior. I will fix it. Thanks!
>
>>>
>>> One nitpick below.
>>>
>>> Thanks,
>>> Song
>>>
>>> [...]
>>>>
>>>> +struct bperf_filter_value {
>>>> + __u32 accum_key;
>>>> + __u8 exited;
>>>> +};
>>> nit:
>>> Can we use a special value of accum_key to replace exited==1
>>> case?
>>
>> I'm not sure. I guess it still needs to use the accum_key to save the
>> final value when exited = 1.
>
> In theory, it is possible. The accum_key is currently only used to index value
> in accum_readings map, so if the task is not being counted, the accum_key can
> be set to an special value.
>
> Due to accum_key is of u32 type, there are two special values to choose from: 0
> or max_entries+1. I think the latter, max_entries+1, may be more suitable because
> it can avoid memory waste in the accum_readings map and does not require too
> many changes to bpf_counter.
>
Sorry, I was wrong. As Namhyung said, 'accum_readings[accum_key]' saves the
last count of the task when it exits. If accum_key is set to a special value
at this time, the count will be lost.
So exited==1 is necessary, we can not use a special value of accum_key to
replace it.
Thanks,
Tengda
>
>>
>> Thanks,
>> Namhyung
>>
>>>
>>>> +
>>>> #endif /* __BPERF_STAT_U_H */
>>>> --
>>>> 2.34.1
>>>>
>
On Thu, Oct 10, 2024 at 8:07 PM Tengda Wu <wutengda@huaweicloud.com> wrote:
[...]
> >>>>
> >>>> +struct bperf_filter_value {
> >>>> + __u32 accum_key;
> >>>> + __u8 exited;
> >>>> +};
> >>> nit:
> >>> Can we use a special value of accum_key to replace exited==1
> >>> case?
> >>
> >> I'm not sure. I guess it still needs to use the accum_key to save the
> >> final value when exited = 1.
> >
> > In theory, it is possible. The accum_key is currently only used to index value
> > in accum_readings map, so if the task is not being counted, the accum_key can
> > be set to an special value.
> >
> > Due to accum_key is of u32 type, there are two special values to choose from: 0
> > or max_entries+1. I think the latter, max_entries+1, may be more suitable because
> > it can avoid memory waste in the accum_readings map and does not require too
> > many changes to bpf_counter.
> >
>
> Sorry, I was wrong. As Namhyung said, 'accum_readings[accum_key]' saves the
> last count of the task when it exits. If accum_key is set to a special value
> at this time, the count will be lost.
>
> So exited==1 is necessary, we can not use a special value of accum_key to
> replace it.
Got it. Thanks for the explanation.
Song
© 2016 - 2024 Red Hat, Inc.