Messages in this thread Patch in this message | | | Subject | ktimers in RT causing bad bogomips and more. | From | Steven Rostedt <> | Date | Tue, 25 Oct 2005 18:15:41 -0400 |
| |
Hi Thomas,
A colleague of mine at my customer site (also named Thomas), noticed that the Bogomips of Ingo's kernel did not match the Bogomips of the 2.6.14-rc5 kernel. I had other problems at the time to take a look, but my machine at home is showing weirdness that was seen on that machine the other Thomas had. So I started taking a look into the cause for the differences in the bogomips.
Well, you seem to have the jiffies running wild. At least for start up.
First, lets take a look at where jiffies is incremented. That's done by do_timer, which is called in clockevents.c by handle_tick, handle_tick_update and handle_tick_update_profile. So when any of these functions are called, jiffies is incremented. Is that expected?
This gets even more complex, since handle_tick is called by handle_next_event_tick, handle_next_event_tick_update and handle_next_event_all.
Now these functions call handle_tick several times, determined by the value returned by ktimer_interrupt.
For example:
static void handle_nextevent_tick(struct pt_regs *regs) { int res;
res = ktimer_interrupt(); for (; res > 0; res--) handle_tick(regs); }
Now looking at ktimer_interrupt, the beginning looks like this:
int ktimer_interrupt(void) { struct ktimer_base *base; ktime_t expires_next, now; int i, raise = 0, ret = 0; int cpu = smp_processor_id(); struct ktimer_hres *hres = &per_cpu(ktimer_hres, cpu);
/* As long as we did not switch over to high resolution mode * we expect, that the event source is running in periodic * mode when it is a source serving other (tick based) * functionality than next event * */ if (!hres->active) return CLOCK_EVT_RUN_CYCLIC;
Is it really expected to call handle_ticks CLOCK_EVT_RUN_CYCLIC times? :-) I don't think so (It's seven BTW).
So, I figured the following patch might be in order. Thomas, what do you think?
It at least makes my bogomips go back to 736.41 from 74.27 :-)
-- Steve
Index: rt_linux_ernie/kernel/ktimers.c =================================================================== --- rt_linux_ernie.orig/kernel/ktimers.c 2005-10-25 08:49:42.000000000 -0400 +++ rt_linux_ernie/kernel/ktimers.c 2005-10-25 18:03:21.000000000 -0400 @@ -341,7 +341,7 @@ * */ if (!hres->active) - return CLOCK_EVT_RUN_CYCLIC; + return -CLOCK_EVT_RUN_CYCLIC; now = do_ktime_get(); Index: rt_linux_ernie/kernel/time/clockevents.c =================================================================== --- rt_linux_ernie.orig/kernel/time/clockevents.c 2005-10-25 18:02:33.000000000 -0400 +++ rt_linux_ernie/kernel/time/clockevents.c 2005-10-25 18:07:07.000000000 -0400 @@ -167,6 +167,10 @@ int res; res = ktimer_interrupt(); + + if (res == -CLOCK_EVT_RUN_CYCLIC) + res = 1; + for (; res > 0; res--) handle_tick(regs); } @@ -190,6 +194,9 @@ if ((res = ktimer_interrupt()) == 0) return; + if (res == -CLOCK_EVT_RUN_CYCLIC) + res = 1; + for (; res > 0; res--) handle_tick(regs); @@ -224,6 +231,9 @@ if ((res = ktimer_interrupt()) == 0) return; + if (res == -CLOCK_EVT_RUN_CYCLIC) + res = 1; + for (; res > 0; res--) handle_tick(regs); Either the above patch, or just have ktimer_interrupt return 1. But I figured that you want to differentiate this. But maybe not.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |