From: Mark Rutland <mark.rutland@arm.com> To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@kernel.org, mark.rutland@arm.com, mingo@redhat.com, peterz@infradead.org, will.deacon@arm.com Subject: [RFCv4 6/7] perf: util: only open events on CPUs an evsel permits Date: Thu, 8 Sep 2016 11:21:51 +0100 [thread overview] Message-ID: <1473330112-28528-7-git-send-email-mark.rutland@arm.com> (raw) In-Reply-To: <1473330112-28528-1-git-send-email-mark.rutland@arm.com> In systems with heterogeneous CPU PMUs, it's possible for each evsel to cover a distinct set of CPUs, and hence the cpu_map associated with each evsel may have a distinct idx<->id mapping. Any of these may be distinct from the evlist's cpu map. Events can be tied to the same fd so long as they use the same per-cpu ringbuffer (i.e. so long as they are on the same CPU). To acquire the correct FDs, we must compare the Linux logical IDs rather than the evsel or evlist indices. This path adds logic to perf_evlist__mmap_per_evsel to handle this, translating IDs as required. As PMUs may cover a subset of CPUs from the evlist, we skip the CPUs a PMU cannot handle. Without this patch, perf record may try to mmap erroneous FDs on heterogeneous systems, and will bail out early rather than running the workload. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel@vger.kernel.org --- tools/perf/util/evlist.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index 097b3ed..ea34c5a 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -1032,16 +1032,18 @@ perf_evlist__should_poll(struct perf_evlist *evlist __maybe_unused, } static int perf_evlist__mmap_per_evsel(struct perf_evlist *evlist, int idx, - struct mmap_params *mp, int cpu, + struct mmap_params *mp, int cpu_idx, int thread, int *_output, int *_output_backward) { struct perf_evsel *evsel; int revent; + int evlist_cpu = cpu_map__cpu(evlist->cpus, cpu_idx); evlist__for_each_entry(evlist, evsel) { struct perf_mmap *maps = evlist->mmap; int *output = _output; int fd; + int cpu; if (evsel->attr.write_backward) { output = _output_backward; @@ -1060,6 +1062,10 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist *evlist, int idx, if (evsel->system_wide && thread) continue; + cpu = cpu_map__idx(evsel->cpus, evlist_cpu); + if (cpu == -1) + continue; + fd = FD(evsel, cpu, thread); if (*output == -1) { -- 1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland) To: linux-arm-kernel@lists.infradead.org Subject: [RFCv4 6/7] perf: util: only open events on CPUs an evsel permits Date: Thu, 8 Sep 2016 11:21:51 +0100 [thread overview] Message-ID: <1473330112-28528-7-git-send-email-mark.rutland@arm.com> (raw) In-Reply-To: <1473330112-28528-1-git-send-email-mark.rutland@arm.com> In systems with heterogeneous CPU PMUs, it's possible for each evsel to cover a distinct set of CPUs, and hence the cpu_map associated with each evsel may have a distinct idx<->id mapping. Any of these may be distinct from the evlist's cpu map. Events can be tied to the same fd so long as they use the same per-cpu ringbuffer (i.e. so long as they are on the same CPU). To acquire the correct FDs, we must compare the Linux logical IDs rather than the evsel or evlist indices. This path adds logic to perf_evlist__mmap_per_evsel to handle this, translating IDs as required. As PMUs may cover a subset of CPUs from the evlist, we skip the CPUs a PMU cannot handle. Without this patch, perf record may try to mmap erroneous FDs on heterogeneous systems, and will bail out early rather than running the workload. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel at vger.kernel.org --- tools/perf/util/evlist.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index 097b3ed..ea34c5a 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -1032,16 +1032,18 @@ perf_evlist__should_poll(struct perf_evlist *evlist __maybe_unused, } static int perf_evlist__mmap_per_evsel(struct perf_evlist *evlist, int idx, - struct mmap_params *mp, int cpu, + struct mmap_params *mp, int cpu_idx, int thread, int *_output, int *_output_backward) { struct perf_evsel *evsel; int revent; + int evlist_cpu = cpu_map__cpu(evlist->cpus, cpu_idx); evlist__for_each_entry(evlist, evsel) { struct perf_mmap *maps = evlist->mmap; int *output = _output; int fd; + int cpu; if (evsel->attr.write_backward) { output = _output_backward; @@ -1060,6 +1062,10 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist *evlist, int idx, if (evsel->system_wide && thread) continue; + cpu = cpu_map__idx(evsel->cpus, evlist_cpu); + if (cpu == -1) + continue; + fd = FD(evsel, cpu, thread); if (*output == -1) { -- 1.9.1
next prev parent reply other threads:[~2016-09-08 10:22 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-08 10:21 [RFCv4 0/7] arm_pmu/perf tools: play nicely with CPU PMU cpumasks Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-08 10:21 ` [RFCv4 1/7] drivers/perf: arm_pmu: add common attr group fields Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-09 10:25 ` Will Deacon 2016-09-09 10:25 ` Will Deacon 2016-09-09 11:05 ` Mark Rutland 2016-09-09 11:05 ` Mark Rutland 2016-09-08 10:21 ` [RFCv4 2/7] arm64: perf: move to common attr_group fields Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-08 10:21 ` [RFCv4 3/7] arm: " Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-08 10:21 ` [RFCv4 4/7] drivers/perf: arm_pmu: only use common attr_groups Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-08 10:21 ` [RFCv4 5/7] drivers/perf: arm_pmu: expose a cpumask in sysfs Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-09 10:24 ` Will Deacon 2016-09-09 10:24 ` Will Deacon 2016-09-09 11:04 ` Mark Rutland 2016-09-09 11:04 ` Mark Rutland 2016-09-08 10:21 ` Mark Rutland [this message] 2016-09-08 10:21 ` [RFCv4 6/7] perf: util: only open events on CPUs an evsel permits Mark Rutland 2016-09-09 5:53 ` [tip:perf/core] perf evlist: Only " tip-bot for Mark Rutland 2016-09-08 10:21 ` [RFCv4 7/7] perf: util: support alternative sysfs cpumask Mark Rutland 2016-09-08 10:21 ` Mark Rutland 2016-09-09 5:54 ` [tip:perf/core] perf pmu: Support " tip-bot for Mark Rutland 2016-09-08 10:38 ` [RFCv4 0/7] arm_pmu/perf tools: play nicely with CPU PMU cpumasks Will Deacon 2016-09-08 10:38 ` Will Deacon 2016-09-08 11:29 ` Mark Rutland 2016-09-08 11:29 ` Mark Rutland 2016-09-08 16:25 ` Arnaldo Carvalho de Melo 2016-09-08 16:25 ` Arnaldo Carvalho de Melo 2016-09-08 18:16 ` Peter Zijlstra 2016-09-08 18:16 ` Peter Zijlstra 2016-09-09 9:31 ` Will Deacon 2016-09-09 9:31 ` Will Deacon
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=1473330112-28528-7-git-send-email-mark.rutland@arm.com \ --to=mark.rutland@arm.com \ --cc=acme@kernel.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=jolsa@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=will.deacon@arm.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.