From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/11] arm64: pmu: Provide cpumask attribute for PMU
Date: Mon, 11 Jul 2016 16:58:35 +0100 [thread overview]
Message-ID: <20160711155834.GC7691@leverpostej> (raw)
In-Reply-To: <5783B5C3.8090000@arm.com>
On Mon, Jul 11, 2016 at 10:05:39AM -0500, Jeremy Linton wrote:
> Hi,
>
> On 07/07/2016 11:21 AM, Mark Rutland wrote:
> >Hi Jeremy,
> >
> >Apologies for the late reply on this.
> >
> >On Tue, Jun 21, 2016 at 12:11:46PM -0500, Jeremy Linton wrote:
> >>With heterogeneous PMUs its helpful to know which PMUs are bound
> >>to each CPU. Provide that information with a cpumask sysfs entry
> >>similar to other PMUs.
> >
> >Have you tested trying to stat on a particular PMU? e.g.
> >
> >$ perf stat -e armv8_cortex_a53/cpu_cycles/ ls
> >
> >I found that the presence of a cpumask file would cause (at least some
> >versions) of perf-stat to hang, and was holding off adding a cpumask
> >until we had a solution to that.
>
> Nice!
>
> I guess that is more proof that any tiny change can break things..
> Another "fix" is to make the cpumap_print_to_pagebuf's first
> parameter false which apparently keeps perf from understanding the
> cpu mask and forces the user to use numactl, which is ugly because
> numactrl doesn't understand the mask in that format either.
If we have a cpumask, it should be in keeping with the usual style.
> I guess fixing perf is probably the best bet here...
Indeed.
The major issue is that it's not clear to me how to avoid breaking
existing binaries when adding the cpumask. I suspect that we have to
expose it under a different name. :/
> >See [1,2] for more details on that.
> >
> >>Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> >>---
> >> arch/arm64/kernel/perf_event.c | 21 +++++++++++++++++++++
> >> 1 file changed, 21 insertions(+)
> >
> >This should be generic across the arm-pmu code, and so should live under
> >drivers/perf/.
>
> Which is where i had it initially, but (IIRC) getting to work there
> required some core pmu changes that seemed a little ugly.
That was my experience from local refactoring, too.
> I guess I didn't like the idea of reallocating the per pmu attr group
> or tweaking the pmu core code.. So I just moved it into perf_event
> where it fit more naturally.
I don't think we need to allocate the attr group per pmu (we get the PMU
pointer from the dev, so the attr group can be shared).
I think we can share the logic, the cpumask attr, and the cpumask
attr_group in drivers/perf/arm_pmu.c, exposing a common
arm_pmu_cpumask_attr_group pointer via the arm_pmu header.
Then all each driver needs to wire up is a single pointer in its
attr_groups array, which isn't so bad.
Thanks,
Mark.
>
>
>
> >
> >Thanks,
> >Mark.
> >
> >[1] http://lkml.kernel.org/r/1467907474-3290-1-git-send-email-mark.rutland at arm.com
> >[2] http://lkml.kernel.org/r/1467907474-3290-2-git-send-email-mark.rutland at arm.com
> >
> >>diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> >>index 356fa6c..dae73ea 100644
> >>--- a/arch/arm64/kernel/perf_event.c
> >>+++ b/arch/arm64/kernel/perf_event.c
> >>@@ -533,6 +533,26 @@ static struct attribute_group armv8_pmuv3_events_attr_group = {
> >>
> >> PMU_FORMAT_ATTR(event, "config:0-9");
> >>
> >>+static ssize_t
> >>+cpumask_show(struct device *dev, struct device_attribute *attr, char *page)
> >>+{
> >>+ struct pmu *pmu = dev_get_drvdata(dev);
> >>+ struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
> >>+
> >>+ return cpumap_print_to_pagebuf(true, page, &cpu_pmu->supported_cpus);
> >>+}
> >>+static DEVICE_ATTR_RO(cpumask);
> >>+
> >>+static struct attribute *armv8_pmuv3_attrs[] = {
> >>+ &dev_attr_cpumask.attr,
> >>+ NULL,
> >>+};
> >>+
> >>+static struct attribute_group armv8_pmuv3_attr_group = {
> >>+ .attrs = armv8_pmuv3_attrs,
> >>+};
> >>+
> >>+
> >> static struct attribute *armv8_pmuv3_format_attrs[] = {
> >> &format_attr_event.attr,
> >> NULL,
> >>@@ -544,6 +564,7 @@ static struct attribute_group armv8_pmuv3_format_attr_group = {
> >> };
> >>
> >> static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
> >>+ &armv8_pmuv3_attr_group,
> >> &armv8_pmuv3_events_attr_group,
> >> &armv8_pmuv3_format_attr_group,
> >> NULL,
> >>--
> >>2.5.5
> >>
> >
>
next prev parent reply other threads:[~2016-07-11 15:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 17:11 [PATCH v6 00/11] Enable PMUs in ACPI systems Jeremy Linton
2016-06-21 17:11 ` [PATCH 01/11] arm64: pmu: add fallback probe table Jeremy Linton
2016-06-21 17:11 ` [PATCH 02/11] arm64: pmu: Probe default hw/cache counters Jeremy Linton
2016-06-21 17:11 ` [PATCH 03/11] arm64: pmu: Hoist pmu platform device name Jeremy Linton
2016-06-21 17:11 ` [PATCH 04/11] arm64: Rename the common MADT parse routine Jeremy Linton
2016-06-21 17:11 ` [PATCH 05/11] arm64: pmu: Add support for probing with ACPI Jeremy Linton
2016-07-06 16:45 ` Will Deacon
2016-06-21 17:11 ` [PATCH 06/11] arm: arm64: Add routine to determine cpuid of other cpus Jeremy Linton
2016-07-06 16:30 ` Will Deacon
2016-07-07 0:34 ` Jeremy Linton
2016-06-21 17:11 ` [PATCH 07/11] arm: arm64: pmu: Assign platform PMU CPU affinity Jeremy Linton
2016-07-01 14:00 ` Punit Agrawal
2016-06-21 17:11 ` [PATCH 08/11] arm64: pmu: Provide cpumask attribute for PMU Jeremy Linton
2016-07-07 16:21 ` Mark Rutland
2016-07-11 15:05 ` Jeremy Linton
2016-07-11 15:58 ` Mark Rutland [this message]
2016-07-11 16:14 ` Will Deacon
2016-06-21 17:11 ` [PATCH 09/11] arm64: pmu: Add routines for detecting differing PMU types in the system Jeremy Linton
2016-07-01 13:58 ` Punit Agrawal
2016-07-01 14:54 ` Jeremy Linton
2016-07-01 15:43 ` Punit Agrawal
2016-07-01 16:21 ` Jeremy Linton
2016-07-01 15:28 ` Jeremy Linton
2016-06-21 17:11 ` [PATCH 10/11] arm64: pmu: Enable multiple PMUs in an ACPI system Jeremy Linton
2016-07-01 13:57 ` Punit Agrawal
2016-06-21 17:11 ` [PATCH 11/11] MAINTAINERS: Tweak ARM PMU maintainers Jeremy Linton
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=20160711155834.GC7691@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.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