linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Zippel <zippel@linux-m68k.org>
To: john stultz <johnstul@us.ibm.com>
Cc: Valdis.Kletnieks@vt.edu, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Uwe Bugla <uwe.bugla@gmx.de>
Subject: Re: 2.6.17-mm2 hrtimer code wedges at boot?
Date: Sat, 8 Jul 2006 01:16:29 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0607070134020.12900@scrub.home> (raw)
In-Reply-To: <1152223506.24656.173.camel@cog.beaverton.ibm.com>

Hi,

On Thu, 6 Jul 2006, john stultz wrote:

> Yea. I've been trying to map your method to the PID concept as well
> (when all you have is a hammer... ;) and they are similar, however the
> "future error" aspect of yours makes it a little more difficult to
> grasp, but it is more compact.

Let's take a different example model - let's take two cars, where one car 
tries to follow the other, but it's limited in how it can change the speed 
(and sometimes the driver also falls asleep :) ).
First we want to match of course the speed of both cars, so that the 
distance between the cars increases as little as possible over time. 
Second we want to decrease the distance between the cars. The problem is 
to stop the correction when the distance is near zero, which is simple 
when we know the next time, we can change the speed, but if we miss the 
point we overshoot and the distance grows again.
It's possible to keep these two parameters separate, but it's actually 
simpler to look at them together, by simply looking some time ahead and 
calculate the position of the car at this time and thus the speed of the 
other car to reach this position.

The adjustment code basically does just this by using the difference in 
speed to calculate the upcoming error. The new patch now uses the current 
error to decide by how much to look ahead, basically if we already have a 
large error, we have to be more careful, but overshooting with a small 
adjustment doesn't do much harm.
In the patch below I left some debug prints, which are useful to check how 
good the error adjustment works. It should be close to the final version 
(minus the prints and plus some more comments).

> > Regarding dynticks it would help a lot here to know how many ticks are 
> > skipped so you can spread the error correction evenly over this period 
> > until the next adjustment and the correction is stopped in time.
> 
> I've considered alternatives, where we use a constant gain with the
> proportional component (so any proportional change would be spread over
> one second), but to avoid constant offsets when the total error was
> smaller then the gain factor, we could also calculate a non-gain'ed
> adjustment w/ a limiter and include that. This would be more ideal in
> your irregular ticks example, but I'm not sure its really that much more
> beneficial from what I proposed.

The problem is we have conflicting goals, adjusting for an unknown number 
of lost ticks is bad for precise timekeeping. I prefer to assume that lost 
ticks are the exceptions and we need the help from the dynticks code to 
assure precise timekeeping.

bye, Roman


---
 kernel/timer.c |   89 +++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 56 insertions(+), 33 deletions(-)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-07-07 02:51:57.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-07-07 23:58:47.000000000 +0200
@@ -1013,15 +1013,9 @@ device_initcall(timekeeping_init_device)
  */
 static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset)
 {
-	int adj;
+	s64 e, i;
+	int adj, mult;
 
-	/*
-	 * As soon as the machine is synchronized to the external time
-	 * source this should be the common case.
-	 */
-	error >>= 2;
-	if (likely(sign > 0 ? error <= *interval : error >= *interval))
-		return sign;
 
 	/*
 	 * An extra look ahead dampens the effect of the current error,
@@ -1029,33 +1023,41 @@ static __always_inline int clocksource_b
 	 * it would dominate the adjustment value and can lead to
 	 * oscillation.
 	 */
-	error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1);
-	error -= clock->xtime_interval >> 1;
-
-	adj = 0;
-	while (1) {
-		error >>= 1;
-		if (sign > 0 ? error <= *interval : error >= *interval)
-			break;
-		adj++;
+	e = (sign > 0 ? clock->error : -clock->error) >> (TICK_LENGTH_SHIFT + 20 - 2 * SHIFT_HZ);
+	for (adj = 0; (e >>= 2) > 0; adj++)
+		;
+	error >>= adj;
+	e = current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift);
+	e -= clock->xtime_interval;
+	error += e;
+	error -= e >> (adj + 1);
+
+	i = *interval;
+	mult = 1;
+	if (error < 0) {
+		error = -error;
+		*interval = -*interval;
+		*offset = -*offset;
+		mult = -1;
+	}
+
+	if (error <= i) {
+		*interval = 0;
+		*offset = 0;
+		return 0;
 	}
 
-	/*
-	 * Add the current adjustments to the error and take the offset
-	 * into account, the latter can cause the error to be hardly
-	 * reduced at the next tick. Check the error again if there's
-	 * room for another adjustment, thus further reducing the error
-	 * which otherwise had to be corrected at the next update.
-	 */
-	error = (error << 1) - *interval + *offset;
-	if (sign > 0 ? error > *interval : error < *interval)
-		adj++;
+	for (adj = 0; (error >>= 1) > i; adj++)
+		;
 
 	*interval <<= adj;
 	*offset <<= adj;
-	return sign << adj;
+	return mult << adj;
 }
 
+static unsigned long next_print = INITIAL_JIFFIES;
+static int big_cnt, one_cnt, zero_cnt;
+
 /*
  * Adjust the multiplier to reduce the error value,
  * this is optimized for the most common adjustments of -1,0,1,
@@ -1066,15 +1068,36 @@ static void clocksource_adjust(struct cl
 	s64 error, interval = clock->cycle_interval;
 	int adj;
 
+	if (time_after(jiffies, next_print)) {
+		printk("adj: %d,%d,%d\n", zero_cnt, one_cnt, big_cnt);
+		zero_cnt = one_cnt = big_cnt = 0;
+		next_print = jiffies + 10 * HZ;
+	}
 	error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1);
 	if (error > interval) {
-		adj = clocksource_bigadjust(1, error, &interval, &offset);
+		error >>= 2;
+		if (likely(error <= interval)) {
+			one_cnt++;
+			adj = 1;
+		} else {
+			big_cnt++;
+			adj = clocksource_bigadjust(1, error, &interval, &offset);
+		}
 	} else if (error < -interval) {
-		interval = -interval;
-		offset = -offset;
-		adj = clocksource_bigadjust(-1, error, &interval, &offset);
-	} else
+		error >>= 2;
+		if (likely(error >= -interval)) {
+			one_cnt++;
+			adj = -1;
+			interval = -interval;
+			offset = -offset;
+		} else {
+			big_cnt++;
+			adj = clocksource_bigadjust(-1, error, &interval, &offset);
+		}
+	} else {
+		zero_cnt++;
 		return;
+	}
 
 	clock->mult += adj;
 	clock->xtime_interval += interval;

  reply	other threads:[~2006-07-07 23:16 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-24 13:19 2.6.17-mm2 Andrew Morton
2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki
2006-06-24 17:20   ` 2.6.17-mm2 Dave Jones
2006-06-24 21:34     ` 2.6.17-mm2 Andrew Morton
2006-06-25  8:51       ` 2.6.17-mm2 Rafael J. Wysocki
2006-06-25 10:22         ` 2.6.17-mm2 Andrew Morton
2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
2006-06-25 18:23             ` 2.6.17-mm2 Sam Ravnborg
2006-06-25 18:40               ` 2.6.17-mm2 Andrew Morton
2006-06-25 21:21                 ` 2.6.17-mm2 Sam Ravnborg
2006-06-30  7:38             ` 2.6.17-mm2 Randy.Dunlap
2006-07-02 10:11               ` 2.6.17-mm2 Russell King
2006-07-02 18:42                 ` 2.6.17-mm2 Randy.Dunlap
2006-07-02 18:47                   ` 2.6.17-mm2 Arjan van de Ven
2006-07-02 18:47                   ` 2.6.17-mm2 Sam Ravnborg
2006-07-03  5:50                 ` 2.6.17-mm2 Randy.Dunlap
2006-07-03 13:49                   ` 2.6.17-mm2 Russell King
2006-06-25 19:19           ` 2.6.17-mm2 Rafael J. Wysocki
2006-06-26 20:13           ` 2.6.17-mm2 Chandra Seetharaman
2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall
2006-06-24 21:43   ` 2.6.17-mm2 Andrew Morton
2006-06-25  6:06 ` 2.6.17-mm2 Reuben Farrelly
2006-06-25  9:37   ` 2.6.17-mm2 Barry K. Nathan
2006-06-25 10:29     ` 2.6.17-mm2 Reuben Farrelly
2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski
2006-06-25 11:40   ` 2.6.17-mm2 Andrew Morton
2006-06-25 12:18     ` 2.6.17-mm2 Michal Piotrowski
2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall
2006-06-25 17:18   ` Andrew Morton
2006-06-25 18:11     ` Dominik Karall
2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk
2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk
2006-06-26  0:41   ` Vivek Goyal
2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk
2006-06-25 23:27   ` Alan Cox
2006-06-27  1:03   ` Jeff Garzik
2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk
2006-06-26  4:05   ` Steven French
2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk
2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk
2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
2006-06-26 22:50   ` Valdis.Kletnieks
2006-06-26 23:02   ` john stultz
2006-06-26 23:27   ` Thomas Gleixner
2006-06-27  2:12     ` Valdis.Kletnieks
2006-06-27  5:54       ` Thomas Gleixner
2006-06-27 10:16   ` Roman Zippel
2006-06-27 16:43     ` Valdis.Kletnieks
2006-06-27 17:10       ` Roman Zippel
2006-06-27 17:23         ` Roman Zippel
2006-06-27 19:07           ` Valdis.Kletnieks
2006-06-28  0:07             ` john stultz
2006-06-28 10:35               ` Roman Zippel
2006-06-28 11:44                 ` Roman Zippel
2006-06-29 23:07                   ` Valdis.Kletnieks
2006-06-30 19:26                     ` john stultz
2006-06-30 21:04                       ` Valdis.Kletnieks
2006-07-03  1:13                         ` Roman Zippel
2006-07-03  1:56                           ` Daniel Walker
2006-07-03  2:20                             ` Valdis.Kletnieks
2006-07-03 20:08                               ` john stultz
2006-07-03 19:59                             ` john stultz
2006-07-04 22:21                               ` Valdis.Kletnieks
2006-07-05  4:29                           ` Valdis.Kletnieks
2006-07-06  0:37                             ` Roman Zippel
2006-07-06  0:56                               ` john stultz
2006-07-06  6:38                               ` Valdis.Kletnieks
2006-07-06  0:51                             ` john stultz
2006-07-06  1:12                               ` john stultz
2006-07-06  5:43                                 ` john stultz
2006-07-06 20:33                               ` Roman Zippel
2006-07-06 22:05                                 ` john stultz
2006-07-07 23:16                                   ` Roman Zippel [this message]
2006-07-08 20:02                                   ` [PATCH] adjust clock for lost ticks Roman Zippel
2006-07-09 21:25                                     ` john stultz
2006-06-28 23:41                 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz
2006-06-29 11:24                   ` Roman Zippel
2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk
2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk
2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0607070134020.12900@scrub.home \
    --to=zippel@linux-m68k.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@osdl.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=uwe.bugla@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).