From: Adrian Hunter <adrian.hunter@intel.com>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH V2] libperf evlist: Fix per-thread mmaps for multi-threaded targets
Date: Wed, 7 Sep 2022 08:05:27 +0300 [thread overview]
Message-ID: <4763358a-91fa-3607-dd54-749b40f977fc@intel.com> (raw)
In-Reply-To: <YxejRK2/LO7QouOZ@krava>
On 6/09/22 22:45, Jiri Olsa wrote:
> On Tue, Sep 06, 2022 at 05:04:45PM +0300, Adrian Hunter wrote:
>> On 6/09/22 15:59, Jiri Olsa wrote:
>>> On Mon, Sep 05, 2022 at 02:42:09PM +0300, Adrian Hunter wrote:
>>>
>>> SNIP
>>>
>>>> diff --git a/tools/lib/perf/evlist.c b/tools/lib/perf/evlist.c
>>>> index e6c98a6e3908..6b1bafe267a4 100644
>>>> --- a/tools/lib/perf/evlist.c
>>>> +++ b/tools/lib/perf/evlist.c
>>>> @@ -486,6 +486,7 @@ mmap_per_evsel(struct perf_evlist *evlist, struct perf_evlist_mmap_ops *ops,
>>>> if (ops->idx)
>>>> ops->idx(evlist, evsel, mp, idx);
>>>>
>>>> + pr_debug("idx %d: mmapping fd %d\n", idx, *output);
>>>> if (ops->mmap(map, mp, *output, evlist_cpu) < 0)
>>>> return -1;
>>>>
>>>> @@ -494,6 +495,7 @@ mmap_per_evsel(struct perf_evlist *evlist, struct perf_evlist_mmap_ops *ops,
>>>> if (!idx)
>>>> perf_evlist__set_mmap_first(evlist, map, overwrite);
>>>> } else {
>>>> + pr_debug("idx %d: set output fd %d -> %d\n", idx, fd, *output);
>>>> if (ioctl(fd, PERF_EVENT_IOC_SET_OUTPUT, *output) != 0)
>>>> return -1;
>>>>
>>>> @@ -519,6 +521,48 @@ mmap_per_evsel(struct perf_evlist *evlist, struct perf_evlist_mmap_ops *ops,
>>>> return 0;
>>>> }
>>>>
>>>> +static int
>>>> +mmap_per_thread(struct perf_evlist *evlist, struct perf_evlist_mmap_ops *ops,
>>>> + struct perf_mmap_param *mp)
>>>> +{
>>>> + int nr_threads = perf_thread_map__nr(evlist->threads);
>>>> + int nr_cpus = perf_cpu_map__nr(evlist->all_cpus);
>>>> + int cpu, thread, idx = 0;
>>>> + int nr_mmaps = 0;
>>>> +
>>>> + pr_debug("%s: nr cpu values (may include -1) %d nr threads %d\n",
>>>> + __func__, nr_cpus, nr_threads);
>>>
>>> -1 as cpu value is only for 'empty' perf_cpu_map, right?
>>
>> The cpu map is a map of valid 3rd arguments to perf_event_open, so -1
>> means all CPUs which is per-thread by necessity.
>>
>>>
>>>> +
>>>> + /* per-thread mmaps */
>>>> + for (thread = 0; thread < nr_threads; thread++, idx++) {
>>>> + int output = -1;
>>>> + int output_overwrite = -1;
>>>> +
>>>> + if (mmap_per_evsel(evlist, ops, idx, mp, 0, thread, &output,
>>>> + &output_overwrite, &nr_mmaps))
>>>> + goto out_unmap;
>>>> + }
>>>> +
>>>> + /* system-wide mmaps i.e. per-cpu */
>>>> + for (cpu = 1; cpu < nr_cpus; cpu++, idx++) {
>>>> + int output = -1;
>>>> + int output_overwrite = -1;
>>>> +
>>>> + if (mmap_per_evsel(evlist, ops, idx, mp, cpu, 0, &output,
>>>> + &output_overwrite, &nr_mmaps))
>>>> + goto out_unmap;
>>>> + }
>>>
>>> will this loop be executed? we are in here because all_cpus is empty, right?
>>
>> Yes it is executed. I put back the code that was there before ae4f8ae16a07
>> ("libperf evlist: Allow mixing per-thread and per-cpu mmaps"), which uses
>
> hm, but commit ae4f8ae16a07 does not have similar cpu loop
It was calling mmap_per_cpu() for that case.
The 2 cases: mmap_per_cpu() and mmap_per_thread() could still be
combined into a single function.
>
>> perf_cpu_map__empty() which only checks the first entry is -1:
>>
>> bool perf_cpu_map__empty(const struct perf_cpu_map *map)
>> {
>> return map ? map->map[0].cpu == -1 : true;
>> }
>>
>> But there can be more CPUs in the map, so perf_cpu_map__empty()
>> returns true for the per-thread case, as desired, even if there
>> are also system-wide CPUs.
>
> I don't see how, if I'd see -1 together with other cpu values in
> perf_cpu_map I'd think it's a bug, but I might be missing some
> auxtrace usage,
Yes, it is for system-wide collection of events that can affect
every CPU. Currently text_poke is always system-wide - see the
Intel PT example.
>
> I thought we use -1 just for empty cpu map, so in per-thread case
> -1 is properly passed to perf_event_open syscall
Yes, but it does not need to be limited to that case.
>
> jirka
>
>>
>> I guess perf_cpu_map__empty() needs renaming.
>>
>>>
>>> thanks,
>>> jirka
>>>
>>>> +
>>>> + if (nr_mmaps != evlist->nr_mmaps)
>>>> + pr_err("Miscounted nr_mmaps %d vs %d\n", nr_mmaps, evlist->nr_mmaps);
>>>> +
>>>> + return 0;
>>>> +
>>>> +out_unmap:
>>>> + perf_evlist__munmap(evlist);
>>>> + return -1;
>>>> +}
>>>
>>> SNIP
>>
next prev parent reply other threads:[~2022-09-07 5:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 11:42 [PATCH V2] libperf evlist: Fix per-thread mmaps for multi-threaded targets Adrian Hunter
2022-09-06 12:53 ` Arnaldo Carvalho de Melo
2022-09-06 12:59 ` Jiri Olsa
2022-09-06 14:04 ` Adrian Hunter
2022-09-06 17:43 ` Ian Rogers
2022-09-06 21:17 ` Vince Weaver
2022-09-06 19:45 ` Jiri Olsa
2022-09-07 5:05 ` Adrian Hunter [this message]
2022-09-06 17:50 ` Namhyung Kim
2022-09-07 4:52 ` Adrian Hunter
2022-09-07 14:20 ` Jiri Olsa
2022-09-08 15:18 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4763358a-91fa-3607-dd54-749b40f977fc@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=olsajiri@gmail.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).