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
