Re: Fwd: [GIT PULL] timer changes for v3.10
From: Pavel Machek
Date: Wed May 08 2013 - 15:49:29 EST
Hi!
> > > > [...] but some people suspend their machines for longer than that. Plus
> > > > I wonder how it will interfere with /etc/adjtime.
> > >
> > > If it's precise then why should it interfere?
> > >
> > > The history of the TSC being problematic can be ignored the moment CPU
> > > makers fix it completely - and apparently that is happening...
> >
> > AFAICT we normally use RTC/PIT during runtime. If we switch to TSC
>
> No, we do NOT use RTC/PIT during runtime. That's the worst choice one
> could make. If TSC is non frequency constant or affected by C-States
> we use HPET or PM-Timer, and we only ever use the PIT if nothing else
> is available.
>
> RTC is not used at all for timekeeping. RTC is only used at system
> start and when we resume and the TSC stopped during that time, which
> is true for hibernation even on Haswell and newer.
Ok, that was part I was missing.
> > during suspend, surely /etc/adjtime will be confused. (RTC has its own
> > timesource, so it is unlikely to have same error as TSC).
>
> Nothing gets confused. It's all handled proper in the core code and
> the clock source drivers.
Ok, so this patch means that we will use
TSC(runtime)+TSC(s2ram). That's improvement over
TSC(runtime)+RTC(s2ram).
[I still wonder how adjtime is going to work in
TSC(runtime)+RTC(s2disk) case; surely TSC has different drift than
RTC, and so adjtime will have fun trying to estimate the drift... but
that's not new problem and not affected by that patch.]
Ok, thanks for explanation, and sorry it took me so long.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/