From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932537AbcGOKIb (ORCPT ); Fri, 15 Jul 2016 06:08:31 -0400 Received: from foss.arm.com ([217.140.101.70]:48111 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542AbcGOKI2 (ORCPT ); Fri, 15 Jul 2016 06:08:28 -0400 From: Mark Rutland To: linux-kernel@vger.kernel.org Cc: acme@kernel.org, adrian.hunter@intel.com, alexander.shishkin@linux.intel.com, hekuang@huawei.com, jolsa@kernel.org, kan.liang@intel.com, mark.rutland@arm.com, mingo@redhat.com, peterz@infradead.org, wangnan0@huawei.com Subject: [RFCv2 0/4] perf tools: play nicely with CPU PMU cpumasks Date: Fri, 15 Jul 2016 11:08:09 +0100 Message-Id: <1468577293-19667-1-git-send-email-mark.rutland@arm.com> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 prior versions of perf-stat. 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. Today's perf-stat can profile a task in the absence of a cpumask file, but in the presence of one ends up blocking after the profiled task exits. Due to an inconsistency between __perf_evsel__open and read_counter, it ends up treating some uninitialised memory as a file descriptor, and typically ends up blocked on stdin. That can avoided as in patch 1, but existing binaries would be broken by the addition of the cpumask 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? Does it make sense to have a differently-named cpumask file that only new tools will look at? 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 Thanks, Mark. [1] http://lkml.kernel.org/r/1467907474-3290-1-git-send-email-mark.rutland@arm.com Mark Rutland (4): perf stat: balance opening and reading events perf: util: Add more cpu_map helpers perf: util: only open events on CPUs an evsel permits perf: util: support sysfs supported_cpumask file tools/perf/builtin-stat.c | 8 ++++++-- tools/perf/util/cpumap.c | 14 ++++++++++++-- tools/perf/util/cpumap.h | 2 ++ tools/perf/util/evlist.c | 8 +++++++- tools/perf/util/pmu.c | 15 ++++++++++++--- 5 files changed, 39 insertions(+), 8 deletions(-) -- 1.9.1