public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Feng Tang <feng.tang@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	x86@kernel.org, Len Brown <lenb@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.
Date: Mon, 01 Apr 2013 10:32:30 -0700	[thread overview]
Message-ID: <5159C4AE.2050504@linaro.org> (raw)
In-Reply-To: <20130330181451.GF28947@amd.pavel.ucw.cz>

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



  reply	other threads:[~2013-04-01 17:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21  6:38 [RFC PATCH 0/5] Add support for S3 non-stop TSC support Feng Tang
2013-01-21  6:38 ` [RFC PATCH 1/5] x86: Add cpu capability flag X86_FEATURE_TSC_S3_NOTSTOP Feng Tang
2013-01-21  7:27   ` Chen Gong
2013-01-21  7:59     ` Feng Tang
2013-01-21 15:58       ` H. Peter Anvin
2013-01-22 14:07         ` Feng Tang
2013-01-21  6:38 ` [RFC PATCH 2/5] clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NOTSTOP Feng Tang
2013-01-21  6:38 ` [RFC PATCH 3/5] x86: tsc: Add support for new S3_NOTSTOP feature Feng Tang
2013-01-21  6:38 ` [RFC PATCH 4/5] clocksource: Enlarge the maxim time interval when configuring the scale and shift Feng Tang
2013-01-21  7:25   ` Chen Gong
2013-01-21  6:38 ` [RFC PATCH 5/5] timekeeping: Add support for clocksource which doesn't stop during suspend Feng Tang
2013-01-21 13:55 ` [RFC PATCH 0/5] Add support for S3 non-stop TSC support Rafael J. Wysocki
2013-03-30 18:14   ` Pavel Machek
2013-04-01 17:32     ` John Stultz [this message]
2013-04-01 20:31       ` Pavel Machek
2013-04-01 20:41         ` John Stultz
2013-01-21 18:46 ` John Stultz
2013-01-22 14:55   ` Feng Tang
2013-01-22 21:56     ` John Stultz
2013-01-24  3:37       ` Feng Tang
2013-01-24 18:15         ` Jason Gunthorpe
2013-01-22 19:57   ` Jason Gunthorpe
2013-01-22 20:22     ` John Stultz
2013-01-23  0:26       ` Jason Gunthorpe
2013-01-23  0:41         ` John Stultz
2013-01-23  1:37           ` Jason Gunthorpe
2013-01-23  1:54             ` John Stultz
2013-01-23  2:35               ` Jason Gunthorpe
2013-01-23  3:07                 ` John Stultz
2013-01-23 19:23                   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5159C4AE.2050504@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=feng.tang@intel.com \
    --cc=hpa@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox