Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.

From: John Stultz
Date: Mon Apr 01 2013 - 13:38:11 EST


On 03/30/2013 11:14 AM, Pavel Machek wrote:
Hi!

On some new Intel Atom processors (Penwell and Cloverview), there is
a feature that the TSC won't stop S3, say the TSC value won't be
reset to 0 after resume. This feature makes TSC a more reliable
clocksource and could benefit the timekeeping code during system
suspend/resume cycles.

The enabling efforts include adding new flags for this feature,
modifying clocksource.c and timekeeping.c to support and utilizing
it.

One remaining question is inside the timekeeping_resume(), we don't
know if it is called by resuming from suspend(s2ram) or from
hibernate(s2disk), as there is no easy way to check it currently.
But it doesn't hurt as these Penwell/Cloverview platforms only have
S3 state, and no S4.

Please help to review them, thanks!
The patches look reasonable to me.
Not sure... what are advantages? TSC is high resolution, but not
exactly precise time source... and this only makes resume more
complex.
Providing sub-second granularity for suspend time measurement is a pretty compelling use, which greatly reduces time error across suspend/resume.

I agree that the code logic is more complex, but the TSC path should be a good bit faster then hitting the CMOS.
And overall, I'm hoping we can eventually move the RTC based read_persistent_clock() implementations into the rtc core, then allow for clocksource based suspend timing where available (since ARM boards are already basically doing this, but hiding it behind read_persistent_clock() calls).

There is the open concern that given their history, x86 designers will find yet another way to break the TSC in some future chip and we'll end up with non-stop TSCs that run at different frequencies in suspend or some other such nonsense. But we'll just have to detect that and disable functionality where appropriate, much as we do with the TSC now.

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/