[PATCH] Fix BCM1480 doubled process accounting times.
Running a UP kernel on a bcm1480 board, I get nonsensical timing results, like this: release@unknown:~/tmp$ time ./a.out real 0m22.906s user 0m45.792s sys 0m0.010s According to my watch, this program took 23 seconds to run, so the real time clock is OK. It is process accounting that is broken. I tracked this down to a problem with the function bcm1480_timer_interrupt in the file sibyte/bcm1480/time.c. This function calls ll_timer_interrupt for cpu0, and ll_local_timer_interrupt for all cpus. However, both of these functions do process accounting. Thus processes running on cpu0 end up with doubled times. This is very obvious in a UP kernel where all processes run on cpu0. The correct way to do this is to only call ll_local_timer interrupt if this is not cpu0. This can be seen in the mips-board/generic/time.c file, and also in the sibyte/sb1250/time.c file, both of which handle this correctly. I fixed the bcm1480/time.c file by copying over the correct code from the sb1250/time.c file. With this fix, I now get sensible results. release@unknown:~/tmp$ time ./a.out real 0m22.903s user 0m22.894s sys 0m0.006s Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This commit is contained in:
parent
4b29f6043d
commit
e1701fb2e2
1 changed files with 9 additions and 8 deletions
|
@ -110,18 +110,19 @@ void bcm1480_timer_interrupt(struct pt_regs *regs)
|
|||
__raw_writeq(M_SCD_TIMER_ENABLE|M_SCD_TIMER_MODE_CONTINUOUS,
|
||||
IOADDR(A_SCD_TIMER_REGISTER(cpu, R_SCD_TIMER_CFG)));
|
||||
|
||||
if (cpu == 0) {
|
||||
/*
|
||||
* CPU 0 handles the global timer interrupt job
|
||||
*/
|
||||
if (cpu == 0) {
|
||||
ll_timer_interrupt(irq, regs);
|
||||
}
|
||||
|
||||
else {
|
||||
/*
|
||||
* every CPU should do profiling and process accouting
|
||||
* other CPUs should just do profiling and process accounting
|
||||
*/
|
||||
ll_local_timer_interrupt(irq, regs);
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* We use our own do_gettimeoffset() instead of the generic one,
|
||||
|
|
Loading…
Reference in a new issue