lkml.org 
[lkml]   [2005]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Subjectktimers in RT causing bad bogomips and more.
From
Date
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/

\
 
 \ /
  Last update: 2005-10-26 00:18    [W:0.037 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site