Re: [tip:perf/core] perf: Rework the PMU methods

Michael Cree
2010-09-14T10:11:16Z

On 14/09/10 01:18, Peter Zijlstra wrote:
> On Mon, 2010-09-13 at 14:15 +0200, Peter Zijlstra wrote:
>> On Sun, 2010-09-12 at 17:33 +1200, Michael Cree wrote:
>>
>>> I've also tested it on a UP alpha. It worked well for a little while
>>> but after running 'perf top' for a number of seconds I got the following
>>> warning:

>> Ahh, the alpha throttle call should be using the fancy new stop function
>> too (will fold into your earlier patch if it indeed works):
>>
>> As to the point you raised above, yes, I think it would be prudent to
>> call perf_event_do_pending() before update_process_times().
>>
>>
>> Signed-off-by: Peter Zijlstra<a.p.zijlstra@chello.nl>
>
> Damn I suck.. Please try this one.
>
> ---
> Index: linux-2.6/arch/alpha/kernel/perf_event.c
> ===================================================================
> --- linux-2.6.orig/arch/alpha/kernel/perf_event.c
> +++ linux-2.6/arch/alpha/kernel/perf_event.c
> @@ -850,7 +850,7 @@ static void alpha_perf_event_irq_handler
> /* Interrupts coming too quickly; "throttle" the
> * counter, i.e., disable it for a little while.
> */
> - cpuc->idx_mask&= ~(1UL<<idx);
> + alpha_pmu_stop(event, 0);
> }
> }
> wrperfmon(PERFMON_CMD_ENABLE, cpuc->idx_mask);

Thanks, that does the trick. I have had it running for a while without
any problems... Well, except for a new problem which I describe below.
Anyway the above patch has fixed the original problem so can be rolled
into my earlier one as you suggest.

I haven't shifted perf_event_do_pending() before update_process_times()
in the timer interrupt yet. When I get around to it I'll send a patch
through the Alpha maintainer as this is independent of the work on the
core perf event code.

Now to the new problem I saw: I accidently reran 'perf top' while it
was already running, and the second instance of 'perf top' seg-faulted
and the kernel OOPSed with the following:

[ 818.575752] Unable to handle kernel paging request at virtual address
0000000000000060
[ 818.575752] perf(4935): Oops 0
[ 818.575752] pc = [<fffffc000036b8b8>] ra = [<fffffc000036ba3c>] ps
= 0000 Not tainted
[ 818.575752] pc is at put_ctx+0x18/0xb0
[ 818.575752] ra is at free_event+0xec/0x220
[ 818.575752] v0 = 0000000000000000 t0 = 0000000000000000 t1 =
0000000000000002
[ 818.575752] t2 = 0000000000000000 t3 = 0000000000000000 t4 =
fffffc000063e4b0
[ 818.575752] t5 = fffffc0034837000 t6 = fffffc0034837000 t7 =
fffffc003abe0000
[ 818.575752] s0 = 0000000000000000 s1 = 0000000000000000 s2 =
0000000000000000
[ 818.575752] s3 = ffffffffffffffff s4 = 0000000000000000 s5 =
0000000000000053
[ 818.575752] s6 = fffffc0034836c00
[ 818.575752] a0 = 0000000000000000 a1 = fffffc00311a6980 a2 =
0000000000000000
[ 818.575752] a3 = 0000000000000001 a4 = fffffc0000797110 a5 =
00000001200055f8
[ 818.575752] t8 = 0000000000000001 t9 = 00000001200396f4 t10=
0000000000000000
[ 818.575752] t11= 000000000000000a pv = fffffc000031d650 at =
fffffc000036f8bc
[ 818.575752] gp = fffffc00007d6e40 sp = fffffc003abe3e18
[ 818.575752] Disabling lock debugging due to kernel taint
[ 818.575752] Trace:
[ 818.575752] [<fffffc000036ba3c>] free_event+0xec/0x220
[ 818.575752] [<fffffc000036fa24>] SyS_perf_event_open+0x2a4/0x6f0
[ 818.575752] [<fffffc0000310c24>] entSys+0xa4/0xc0
[ 818.575752]
[ 818.575752] Code: 27bb0047 23bdb5a0 23defff0 b53e0008 b75e0000
47f00409 <a8500060> 40403121

The first instance of 'perf top' kept running happily.

Cheers
Michael.