Messages in this thread | | | Subject | Re: [PATCH] timer tsc ensure we allow for initial tsc and tsc sync | From | john stultz <> | Date | Tue, 31 Jan 2006 15:28:23 -0800 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |