On Mon, May 6, 2013 at 4:01 PM, Pavel Machek <pa...@ucw.cz> wrote: > Hi! > >> - suspend/resume enhancements by Feng Tang: on certain new Intel Atom >> processors (Penwell and Cloverview), there is a feature that the TSC >> won't stop in S3 state, so the TSC value won't be reset to 0 after >> resume. This can be taken advantage of by the generic via the >> CLOCK_SOURCE_SUSPEND_NONSTOP flag: instead of using the RTC to >> recover/approximate sleep time, the main (and precise) clocksource can >> be used. > > Ok, so for system time, we use three different timers: > > 1) RTC, while system is off > > 2) PIT, while system is running (plus TSC for parts of second)
? We've not used interpolated timekeeping (PIT + TSC) since 2.6.18/2.6.21. Instead only a single clocksource is used (TSC, hpet, acpi_pm being the most common on x86, and PIT or jiffies on much older systems). > 3) TSC, while system is sleeping So this is only used when the TSC has the SUSPEND_NONSTOP flag. Otherwise we use the CMOS/RTC clock. > Now. we have ntpd that is trying to compute "speed of clock", and > adjust accordingly (adjtimex). But will it still do the right thing > when we switch to different source during sleep? Its true any frequency error we have will grow during suspend. Additionally, if the frequency of the hardware changes during suspend, correcting that will be difficult as well. It has yet to be seen how the TSC hardware that enabled this NONSTOP flag will preform in this regard. If it proves problematic, we'll likely have to add additional checks against the RTC. Even so, I suspect the hardware that likely to gain this feature is targeted for mobile devices where they're likely to wake up periodically. In this case, the extra precision of the fine-grained clocksource, compared to the second granular CMOS is a much greater benefit, as injecting 1second of error on each suspend/resume cycle isn't good for timekeeping either. Additionally, some ARM boards do something very similar with the 32k-timer (albeit hidden behind the persistent_clock interface) so we should eventually be able to share the logic here. > And is the TSC even good enough? According to man page, PIT is not > precise enough, so we sync from RTC every 11 minutes. I'd imagine TSC ?? I think you're confusing the RTC being synced to the system time every 11 minutes while we're in sync w/ ntp servers here. thanks -john -- 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/
