All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Mark Rutland <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: kan.liang@intel.com, adrian.hunter@intel.com,
	wangnan0@huawei.com, hpa@zytor.com, mingo@kernel.org,
	mark.rutland@arm.com, peterz@infradead.org, hekuang@huawei.com,
	tglx@linutronix.de, jolsa@kernel.org, acme@redhat.com,
	linux-kernel@vger.kernel.org, alexander.shishkin@linux.intel.com
Subject: [tip:perf/core] perf stat: Balance opening and reading events
Date: Mon, 18 Jul 2016 23:53:10 -0700	[thread overview]
Message-ID: <tip-00e727bb389359c81101b03d34fec8cc7be5168d@git.kernel.org> (raw)
In-Reply-To: <1468577293-19667-2-git-send-email-mark.rutland@arm.com>

Commit-ID:  00e727bb389359c81101b03d34fec8cc7be5168d
Gitweb:     http://git.kernel.org/tip/00e727bb389359c81101b03d34fec8cc7be5168d
Author:     Mark Rutland <mark.rutland@arm.com>
AuthorDate: Fri, 15 Jul 2016 11:08:10 +0100
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Mon, 18 Jul 2016 19:41:14 -0300

perf stat: Balance opening and reading events

In create_perf_stat_counter, when a target CPU has not been provided, we
call __perf_evsel__open with empty_cpu_map, and open a single FD per
thread. However, in read_counter we assume that we opened events for the
product of threads and CPUs described in the evsel's cpu_map.

Thus, if an evsel has a cpu_map with more than one entry, we will
attempt to access FDs that we didn't open. This could result in a number
of problems (e.g. blocking while reading from STDIN if the fd memory
happened to be initialised to zero).

This is problematic for systems were a logical CPU PMU covers some
arbitrary subset of CPUs. The cpu_map of any evsel for that PMU will be
initialised based on the cpumask exposed through sysfs, even if the user
requests per-thread events.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1468577293-19667-2-git-send-email-mark.rutland@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/builtin-stat.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 8c5a3bf..0c16d20 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -290,8 +290,12 @@ perf_evsel__write_stat_event(struct perf_evsel *counter, u32 cpu, u32 thread,
 static int read_counter(struct perf_evsel *counter)
 {
 	int nthreads = thread_map__nr(evsel_list->threads);
-	int ncpus = perf_evsel__nr_cpus(counter);
-	int cpu, thread;
+	int ncpus, cpu, thread;
+
+	if (target__has_cpu(&target))
+		ncpus = perf_evsel__nr_cpus(counter);
+	else
+		ncpus = 1;
 
 	if (!counter->supported)
 		return -ENOENT;

  parent reply	other threads:[~2016-07-19  6:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 10:08 [RFCv2 0/4] perf tools: play nicely with CPU PMU cpumasks Mark Rutland
2016-07-15 10:08 ` [RFCv2 1/4] perf stat: balance opening and reading events Mark Rutland
2016-07-18 14:32   ` Jiri Olsa
2016-07-19  6:53   ` tip-bot for Mark Rutland [this message]
2016-07-15 10:08 ` [RFCv2 2/4] perf: util: Add more cpu_map helpers Mark Rutland
2016-07-18 14:32   ` Jiri Olsa
2016-07-19  6:53   ` [tip:perf/core] perf cpu_map: Add more helpers tip-bot for Mark Rutland
2016-07-15 10:08 ` [RFCv2 3/4] perf: util: only open events on CPUs an evsel permits Mark Rutland
2016-07-18 14:32   ` Jiri Olsa
2016-07-18 22:46     ` Arnaldo Carvalho de Melo
2016-07-19  6:20       ` Jiri Olsa
2016-07-15 10:08 ` [RFCv2 4/4] perf: util: support sysfs supported_cpumask file Mark Rutland
2016-07-18 14:30   ` Jiri Olsa
2016-07-18 15:00     ` Mark Rutland
2016-07-21  8:10       ` Jiri Olsa
2016-07-21  9:49         ` Mark Rutland
2016-07-18 16:38   ` Suzuki K Poulose
2016-07-18 17:13     ` Mark Rutland

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=tip-00e727bb389359c81101b03d34fec8cc7be5168d@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=hekuang@huawei.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=wangnan0@huawei.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: link
Be 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.