> On Mar 15, 2021, at 7:09 AM, Jiri Olsa <jo...@redhat.com> wrote:
>
> On Mon, Mar 15, 2021 at 07:51:11AM +0000, Song Liu wrote:
>
> SNIP
[...]
>>
>> It is mostly to cover corner cases, like something else used the same
>> name.
>
> about that.. we just take the object fd assuming it's map,
> should we test it somehow?
>
> map_fd = bpf_obj_get(path);
>
> if it's not the map we expect, I think we should generate
> another name without forcing user to run again with --attr-map
>
> but still warn, so other perf session can use the new name
The auto failover is an interesting idea. But I guess we still need
--attr-map. Another use case is when the user mounted bpffs to a
different path. Alternatively, maybe we can teach perf to search all
bpffs mount points for perf_attr_map?
>
> SNIP
>
>>>> +static int bperf_sync_counters(struct evsel *evsel)
>>>> +{
>>>> + struct perf_cpu_map *all_cpus = perf_cpu_map__new(NULL);
>>>> + int num_cpu, i, cpu;
>>>> +
>>>> + if (!all_cpus)
>>>> + return -1;
>>>> +
>>>> + num_cpu = all_cpus->nr;
>>>> + for (i = 0; i < num_cpu; i++) {
>>>> + cpu = all_cpus->map[i];
>>>> + bperf_trigger_reading(evsel->bperf_leader_prog_fd, cpu);
>>>> + }
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int bperf__enable(struct evsel *evsel)
>>>> +{
>>>> + struct bperf_follower_bpf *skel = evsel->follower_skel;
>>>> + __u32 num_cpu_bpf = libbpf_num_possible_cpus();
>>>
>>> we have cpu__max_cpu for that
>>
>> libbpf calls for percpu array use libbpf_num_possible_cpus. So I guess it
>> is better to use the same here. The two are identical at the moment though.
>
> then in the bperf__read you take that array and update
> perf_counts, which is based on perf's cpus, so they mix
> anyway
>
> I'd like to keep perf code using perf's cpus api.. could
> we just check at the begining that libbpf_num_possible_cpus
> returns same number as cpu__max_cpu (if not, we have a
> problem anyway) and use perf's cpu api
Let me try cpu__max_cpu.
Thanks,
Song
