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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/