From: John Stultz <john.stultz@linaro.org>
To: Feng Tang <feng.tang@intel.com>
Cc: 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>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org, gong.chen@linux.intel.com
Subject: Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time
Date: Tue, 05 Mar 2013 14:27:34 +0800 [thread overview]
Message-ID: <51359056.60506@linaro.org> (raw)
In-Reply-To: <1362450426-4232-5-git-send-email-feng.tang@intel.com>
On 03/05/2013 10:27 AM, Feng Tang wrote:
> There are some new processors whose TSC clocksource won't stop during
> suspend. Currently, after system resumes, kernel will use persistent
> clock or RTC to compensate the sleep time, but for those new types of
> clocksources, we could skip the special compensation from external
> sources, and just use current clocksource for time recounting.
>
> This can solve some time drift bugs caused by some not-so-accurate or
> error-prone RTC devices.
>
> The current way to count suspened time is first try to use the persistent
> clock, and then try the rtc if persistent clock can't be used. This
> patch will change the trying order to:
> suspend-nonstop clocksource -> persistent clock -> rtc
Thanks for sending out another iteration of this code. Jason's feedback
has been good, but I think this is starting to shape up nicely.
More below
> Signed-off-by: Feng Tang <feng.tang@intel.com>
> ---
> kernel/time/timekeeping.c | 57 ++++++++++++++++++++++++++++++++++++++------
> 1 files changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 9a0bc98..15cc086 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -788,22 +788,63 @@ void timekeeping_inject_sleeptime(struct timespec *delta)
> static void timekeeping_resume(void)
> {
> struct timekeeper *tk = &timekeeper;
> + struct clocksource *clock = tk->clock;
> unsigned long flags;
> - struct timespec ts;
> + struct timespec ts_new, ts_delta;
> + cycle_t cycle_now, cycle_delta;
> + s64 nsec;
>
> - read_persistent_clock(&ts);
> + ts_delta.tv_sec = 0;
> + read_persistent_clock(&ts_new);
>
> clockevents_resume();
> clocksource_resume();
>
> write_seqlock_irqsave(&tk->lock, flags);
>
> - if (timespec_compare(&ts, &timekeeping_suspend_time) > 0) {
> - ts = timespec_sub(ts, timekeeping_suspend_time);
> - __timekeeping_inject_sleeptime(tk, &ts);
> - }
> - /* re-base the last cycle value */
> - tk->clock->cycle_last = tk->clock->read(tk->clock);
> + /*
> + * After system resumes, we need to calculate the suspended time and
> + * compensate it for the OS time. There are 3 sources that could be
> + * used: Nonstop clocksource during suspend, persistent clock and rtc
> + * device.
> + *
> + * One specific platform may have 1 or 2 or all of them, and the
> + * preference will be:
> + * suspend-nonstop clocksource > persistent clock > rtc
> + * The less preferred source will only be tried if there is no better
> + * usable source. The rtc part is handled separately in rtc core code.
> + */
> + cycle_now = clock->read(clock);
So this might be ok for an initial implementation, as on the
non-stop-tsc hardware, the TSC is the best clocksource available. One
concern long term is that there may be cases where the non-stop
clocksource is not the most performant clocksource on a system. In that
case, we may want to use a non-stop clocksource that is not the current
timekeeping clocksource. So that may require some extra clocksource core
interfaces to access the non-stop clocksource instead of using the
timekeeper's clocksource, also we'll have to be sure to use something
other then cycle_last in that case, since we'll need to read the nonstop
clocksource at suspend, rather then trusting that forward_now updates
cycle_last as is done here.
thanks
-john
next prev parent reply other threads:[~2013-03-05 6:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-05 2:27 [RFC PATCH v2 0/4] Add support for S3 non-stop TSC support Feng Tang
2013-03-05 2:27 ` [RFC PATCH v2 1/4] x86: Add cpu capability flag X86_FEATURE_NONSTOP_TSC_S3 Feng Tang
2013-03-05 2:27 ` [RFC PATCH v2 2/4] clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NOTSTOP Feng Tang
2013-03-05 2:27 ` [RFC PATCH v2 3/4] x86: tsc: Add support for new S3_NOTSTOP feature Feng Tang
2013-03-05 2:27 ` [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time Feng Tang
2013-03-05 6:27 ` John Stultz [this message]
2013-03-05 6:38 ` Feng Tang
2013-03-05 6:47 ` John Stultz
2013-03-05 6:59 ` Feng Tang
2013-03-05 3:53 ` [RFC PATCH v2 0/4] Add support for S3 non-stop TSC support Feng Tang
2013-03-05 4:32 ` Jason Gunthorpe
2013-03-05 6:17 ` John Stultz
2013-03-06 3:31 ` Feng Tang
2013-03-05 6:27 ` Feng Tang
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=51359056.60506@linaro.org \
--to=john.stultz@linaro.org \
--cc=feng.tang@intel.com \
--cc=gong.chen@linux.intel.com \
--cc=hpa@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.