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

[john stultz <johnstul@us.ibm.com>]

On Tue, 2006-01-31 at 15:21 -0800, Andrew Morton wrote:
> Andy Whitcroft <apw@shadowen.org> wrote:
> >
> > From: John Stultz <johnstul@us.ibm.com>
> > 
> > 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@shadowen.org>
> > 
> > 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