Re: [tip:perf/core] perf: Rework the PMU methods
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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@xxxxxxxxx>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. -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html