Re: [PATCH] timer tsc ensure we allow for initial tsc and tsc sync

From: john stultz
Date: Tue Jan 31 2006 - 18:26:45 EST


On Tue, 2006-01-31 at 15:21 -0800, Andrew Morton wrote:
> Andy Whitcroft <apw@xxxxxxxxxxxx> wrote:
> >
> > From: John Stultz <johnstul@xxxxxxxxxx>
> >
> > Suppress lost tick detection until we are fully initialised.
> > This prevents any modifications to the high resolution timers
> > from causing non-linearities in the flow of time. For example on
> > an SMP system we resyncronise the TSC values for all processors.
> > This results in a TSC reset which will be seen as a huge apparent
> > tick loss. This can cause premature expiry of timers and in extreme
> > cases can cause the soft lockup detection to fire.
> >
> > Acked-by: Andy Whitcroft <apw@xxxxxxxxxxxx>
> >
> > diff --git a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
> > --- a/arch/i386/kernel/timers/timer_tsc.c
> > +++ b/arch/i386/kernel/timers/timer_tsc.c
> > @@ -45,6 +45,15 @@ static unsigned long last_tsc_high; /* m
> > static unsigned long long monotonic_base;
> > static seqlock_t monotonic_lock = SEQLOCK_UNLOCKED;
> >
> > +/* Avoid compensating for lost ticks before TSCs are synched */
> > +static int detect_lost_ticks;
> > +static int __init start_lost_tick_compensation(void)
> > +{
> > + detect_lost_ticks = 1;
> > + return 0;
> > +}
> > +late_initcall(start_lost_tick_compensation);
> > +
> > /* convert from cycles(64bits) => nanoseconds (64bits)
> > * basic equation:
> > * ns = cycles / (freq / ns_per_sec)
> > @@ -196,7 +205,8 @@ static void mark_offset_tsc_hpet(void)
> >
> > /* lost tick compensation */
> > offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
> > - if (unlikely(((offset - hpet_last) > hpet_tick) && (hpet_last != 0))) {
> > + if (unlikely(((offset - hpet_last) > hpet_tick) && (hpet_last != 0))
> > + && detect_lost_ticks) {
>
> Simple enough. John, so you feel that this is 2.6.16 material?

Yep. There's a signed off version somewhere in your inbox.

> Note that the time changes in -mm will blow this change away, so I'd be
> needing a fresh version of this patch against next-mm, please.

Uh, not sure I followed that. Do mean you'd want a new set of the
generic timefoday patches to apply ontop of this fix?

thanks
-john

-
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/