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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
