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

[Feng Tang]

Hi Pavel,

On Tue, May 07, 2013 at 09:10:42AM +0800, Feng Tang wrote:
> ---------- Forwarded message ----------
> From: Pavel Machek <pavel@xxxxxx>
> Date: 2013/5/7
> Subject: Re: [GIT PULL] timer changes for v3.10
> To: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>,
> linux-kernel@xxxxxxxxxxxxxxx, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Peter
> Zijlstra <a.p.zijlstra@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> 
> 
> 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)

Not exactly. AFAIK, in most morden x86 processors, the TSC is the primary
clocksource for system time counting.

If you grep clocksource in arch/x86/, there are some clockcources:
HPET, TSC, i8253(PIT you mentioned), APBT and some other xen/kvm clocksources.

Each of them has a "rating", and the clocksource with highest rating will
be selected for system time counting. Here are the ratings:

HPET:	250
TSC:	300
APBT:	250
PIT:	110

So for a system with TSC, unless the TSC is detected or claimed to be
"unstable", it will be used as the runtime clocksource.

> 
> 3) TSC, while system is sleeping

This happens Only if we explicitly claim one processor's TSC has
S3_NONSTOP_TSC feature. Detail could be found in patches. 

For other cases, system will still use persistent_clock or RTC to
calculate the sleep/suspended time

In short, most of existing X86 platforms will not be affected

> 
> 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?
> 
> 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
My understanding, the reason for this 11 minutes sync is due to the
PIT's register value has wrapped around .

> is even worse than that. Machine can stay is s2ram for weeks (for a
> lot more if it is desktop and you do s2ram for powersaving). Also
> temperature of CPU varies a lot between active and s2ram states. Is
> TSC good enough?

Yes, I think it is relatively precise. Per our test, system time backed
by the S3 non stop TSC only has 1 second drift after 4 days running
(with mixed running and S3 states). And before using this feature, we've
seen many time drift problems due to the RTC HW or system FW with our
platforms.

Thanks,
Feng


--
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/