linux-kernel - [RFCv3 0/2] perf tools: play nicely with CPU PMU cpumasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1470933366-1364-1-git-send-email-mark.rutland@arm.com>
Date:	Thu, 11 Aug 2016 17:36:04 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	linux-kernel@...r.kernel.org
Cc:	acme@...nel.org, adrian.hunter@...el.com,
	alexander.shishkin@...ux.intel.com, hekuang@...wei.com,
	jolsa@...nel.org, mark.rutland@....com, mingo@...hat.com,
	peterz@...radead.org, wangnan0@...wei.com
Subject: [RFCv3 0/2] perf tools: play nicely with CPU PMU cpumasks

Hi,

I'm trying to make the perf tool play better with PMUs in heterogeneous systems
(e.g. big.LITTLE). These patches fix some brokenness that exists today, but
they require the addition of a cpumask file to each CPU PMU sysfs directory,
and this happens to break existing perf-stat binaries. Due to this, I have not
yet added a cpumask attribute to the ARM PMU code.

In these system we have separate logical PMUs for discrete sets of CPUs. For
example, on an ARM Juno system we have a logical PMU for all Cortex-A53 CPUs,
and a logical PMU for all the Cortex-A57 CPUs. The logical PMUs allow
task-bound events, but reject CPU-bound events for CPUs they do not cover.

Currently perf-record doesn't work for these PMUs, unless forced to use
per-thread mmaps. In the absence of a cpumask, it tries to open events on CPUs
not supported by a PMU, and gives up. In the presence of a cpumask, it ends up
failing to mmap, as the evlist->cpus map contains a different set of CPUs from
the evsel->cpus map populated from the cpumask.

Prior to commit 00e727bb389359c8 ("perf stat: Balance opening and reading
events"), from version two of this series, perf-stat would behave erroneously
in the presence of a cpumask file, blocking forever after the workload
completed. While this is now fixed, existing binaries (e.g. those shipped by
distributions) would be broken by the addition of a cpumask file kernel-side.

To cater for this, this series adds support for a new PMU sysfs file,
supported_cpus, listing a number of CPUs that a logical PMU covers. As old
binaries will not look for this, this can be safely added to the kernel without
risk of breakage.

Does using a sysfs cpumask to handle (heterogeneous) CPU PMUs feel like the
right approach? Is there perhaps a better way to do this without using a
cpumask?

Does it make sense to have a differently-named cpumask file that only new tools
will look at?

Thanks,
Mark.

Since v1 [1]:
* Avoid double cpu_map__idx() call in perf_evlist__mmap_per_evsel
* Look for a supported_cpumask file when a cpumask file is not present

Since v2 [2]:
* Drop patches which have been picked up from v2
* Rebase to v4.8-rc1
* Better describe the issue in the supported_cpumask patch

[1] http://lkml.kernel.org/r/1467907474-3290-1-git-send-email-mark.rutland@arm.com
[2] http://lkml.kernel.org/r/1468577293-19667-1-git-send-email-mark.rutland@arm.com

Mark Rutland (2):
  perf: util: only open events on CPUs an evsel permits
  perf: util: support sysfs supported_cpumask file

 tools/perf/util/evlist.c |  8 +++++++-
 tools/perf/util/pmu.c    | 15 ++++++++++++---
 2 files changed, 19 insertions(+), 4 deletions(-)

-- 
1.9.1