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;
next prev parent 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).