linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: will.deacon@arm.com, mark.rutland@arm.com
Cc: shawnguo@kernel.org, l.stach@pengutronix.de,
	kernel@pengutronix.de, fabio.estevam@nxp.com, linux-imx@nxp.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Stefan Agner <stefan@agner.ch>
Subject: [PATCH] drivers/perf: handle multiple CPUs with single interrupts
Date: Mon, 21 Jan 2019 15:41:11 +0100	[thread overview]
Message-ID: <20190121144111.22716-1-stefan@agner.ch> (raw)

Currently, if only a single interrupt is available, the code assigns
this single interrupt to the first CPU. All other CPUs are left
unsupported. This allows to use perf events only on processes using
the first CPU. This is not obvious to the user.

Instead, disable interrupts but support all CPUs. This allows to use
the PMU on all CPUs for all events other than sampling events which do
require interrupt support.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
This has been observed and tested on a i.MX 6DualLite, but is probably
valid for i.MX 6Quad as well.

It seems that ux500 once had support for single IRQ on a SMP system,
however this got removed with:
Commit 2b05f6ae1ee5 ("ARM: ux500: remove PMU IRQ bouncer")

I noticed that with this patch I get an error when trying to use perf stat:
  # perf top
  Error:
  cycles: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat'

Without this patch perf top seems to work, but it seems not to use any
sampling events (?):
  # perf top
PerfTop:    7215 irqs/sec  kernel:100.0%  exact:  0.0% [4000Hz cpu-clock:pppH], (all, 2 CPUs)
....

Also starting perf top and explicitly selecting cpu-clock seems to work
and show the same data as before this change.
  # perf top -e cpu-clock:pppH
PerfTop:    7214 irqs/sec  kernel:100.0%  exact:  0.0% [4000Hz cpu-clock:pppH], (all, 2 CPUs)

It seems that perf top falls back to cpu-clock in the old case, but not
once sampling events are not supported...

--
Stefan


 drivers/perf/arm_pmu_platform.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/perf/arm_pmu_platform.c b/drivers/perf/arm_pmu_platform.c
index 933bd8410fc2..80b991417b6e 100644
--- a/drivers/perf/arm_pmu_platform.c
+++ b/drivers/perf/arm_pmu_platform.c
@@ -105,23 +105,26 @@ static int pmu_parse_irqs(struct arm_pmu *pmu)
 		return num_irqs;
 	}
 
+	if (num_irqs == 1) {
+		int irq = platform_get_irq(pdev, 0);
+		if (irq && irq_is_percpu_devid(irq))
+			return pmu_parse_percpu_irq(pmu, irq);
+	}
+
 	/*
 	 * In this case we have no idea which CPUs are covered by the PMU.
 	 * To match our prior behaviour, we assume all CPUs in this case.
+	 * Multiple CPUs with a single PMU irq are currently not handled.
+	 * Rather than supporting only the first CPU, support all CPUs but
+	 * without interrupt capability.
 	 */
-	if (num_irqs == 0) {
-		pr_warn("no irqs for PMU, sampling events not supported\n");
+	if (num_irqs == 0 || (nr_cpu_ids > 1 && num_irqs == 1)) {
+		pr_info("No per CPU irqs for PMU, sampling events not supported\n");
 		pmu->pmu.capabilities |= PERF_PMU_CAP_NO_INTERRUPT;
 		cpumask_setall(&pmu->supported_cpus);
 		return 0;
 	}
 
-	if (num_irqs == 1) {
-		int irq = platform_get_irq(pdev, 0);
-		if (irq && irq_is_percpu_devid(irq))
-			return pmu_parse_percpu_irq(pmu, irq);
-	}
-
 	if (nr_cpu_ids != 1 && !pmu_has_irq_affinity(pdev->dev.of_node)) {
 		pr_warn("no interrupt-affinity property for %pOF, guessing.\n",
 			pdev->dev.of_node);
-- 
2.20.1


             reply	other threads:[~2019-01-21 14:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-21 14:41 Stefan Agner [this message]
2019-01-21 17:23 ` [PATCH] drivers/perf: handle multiple CPUs with single interrupts Mark Rutland
2019-01-22  8:59   ` Stefan Agner

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=20190121144111.22716-1-stefan@agner.ch \
    --to=stefan@agner.ch \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=shawnguo@kernel.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: 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;
as well as URLs for NNTP newsgroup(s).