ktimers in RT causing bad bogomips and more.

[Steven Rostedt]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/