linux-kernel - Re: [patch/rfc] perf on raspberry-pi without overflow interrupt

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Jan 2014 23:23:13 +0100
From:	Stephane Eranian <eranian@...glemail.com>
To:	Vince Weaver <vincent.weaver@...ne.edu>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Will Deacon <will.deacon@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [patch/rfc] perf on raspberry-pi without overflow interrupt

Vince,

I ran into the same problem myself on my Raspberry PI. In fact,
I am really frustrated by ARM platforms not having that IRQ handled
properly. It is pretty common for manufacturers not to provide the code
to route the IRQ, even though the HW does support it. Sometimes the
specs on how to do this are not even public it seems.

Having the PMU IRQ setup properly would make using the PMU on ARM
a lot more attractive.



On Wed, Jan 8, 2014 at 10:28 PM, Vince Weaver <vincent.weaver@...ne.edu> wrote:
>
>
> I'm working on getting the hardware performance counters working on a
> Raspberry-Pi (BCM2835/ARM/1176).
>
> The counters are there, but the overflow interrupt is not hooked up so the
> init code disables perf_event.
>
> The following patch enables perf_event and it works fine for simple
> "perf stat" type workloads.  perf record and anything requiring sampling
> doesn't work (as expected).
>
> I thought I would have to add a periodic timer to catch counter overflows,
> but it turns out that's unnecessary.  From what I can tell even though the
> nPMUIRQ interrupt is not hooked up, the overflows are marked in the status
> register and this is noticed and handled at context-switch time.  So as
> long as the counters overflow less frequently than the context switch
> interval the registers don't overflow.
>
> So my question, is a patch like this acceptable?
>
> Should the perf_event interface handle setups like this better and work
> fine in aggregate mode but return ENOTSUP if a sampled or overflow event
> is attempted?
>
> Vince
>
>
> Signed-off-by: Vince Weaver <vincent.weaver@...ne.edu>
>
> diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
> index d85055c..ff1a752 100644
> --- a/arch/arm/kernel/perf_event_cpu.c
> +++ b/arch/arm/kernel/perf_event_cpu.c
> @@ -97,8 +97,8 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, irq_handler_t handler)
>
>         irqs = min(pmu_device->num_resources, num_possible_cpus());
>         if (irqs < 1) {
> -               pr_err("no irqs for PMUs defined\n");
> -               return -ENODEV;
> +               printk_once("no irqs for PMUs defined, enabling anyway\n");
> +               return 0;
>         }
>
>         for (i = 0; i < irqs; ++i) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/