Re: [GIT PULL] timer changes for v3.10

[John Stultz]

On Mon, May 6, 2013 at 4:01 PM, Pavel Machek <pavel@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/