Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

On Tue, Mar 05, 2013 at 02:47:27PM +0800, John Stultz wrote:
> On 03/05/2013 02:38 PM, Feng Tang wrote:
> >On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:
> >
> >>
> >>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.
> >Yeah, I just realized this when Jason mentioned the counter_32k on
> >OMAP.
> >
> >So for next step, we may add something in timekeeping.c like
> > static struct clocksource *suspend_time_cs;
> >read and save its counter righer before entering and after getting
> >out of suspended state. And create a new struct which includes
> >all time suspend related flags, counters, pointers, make it as a
> >member of struct timekeeper. Comments?
> I'd maybe add it to the clocksource code rather then the timekeeper.
> Have a clocksource_nonstop_clock() accessor which returns a pointer
> to the highest rated clocksource in the clocksource list that has
> the nonstop flag (updating the pointer at registration time, rather
> then scanning the list every time).

Yes, it's more natural to put it in clocksource code if we need to
pick and compare a best non-stop-tsc clocksource.

Thanks,
Feng


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[John Stultz]

On 03/05/2013 02:38 PM, Feng Tang wrote:

On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:



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.

Yeah, I just realized this when Jason mentioned the counter_32k on
OMAP.

So for next step, we may add something in timekeeping.c like
static struct clocksource *suspend_time_cs;
read and save its counter righer before entering and after getting
out of suspended state. And create a new struct which includes
all time suspend related flags, counters, pointers, make it as a
member of struct timekeeper. Comments?
I'd maybe add it to the clocksource code rather then the timekeeper. 
Have a clocksource_nonstop_clock() accessor which returns a pointer to 
the highest rated clocksource in the clocksource list that has the 
nonstop flag (updating the pointer at registration time, rather then 
scanning the list every time).


That way if we want, we can later define clocksource_nonstop_clock() as 
null, and let the complier optimize out the extra complexity in the 
resume path if the arch doesn't support nonstop clocksource.


thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:
> 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.

Thanks :)

> >Signed-off-by: Feng Tang 
> >---
> >  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 = 
> >+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_delta.tv_sec = 0;
> >+read_persistent_clock(_new);
> > clockevents_resume();
> > clocksource_resume();
> > write_seqlock_irqsave(>lock, flags);
> >-if (timespec_compare(, _suspend_time) > 0) {
> >-ts = timespec_sub(ts, timekeeping_suspend_time);
> >-__timekeeping_inject_sleeptime(tk, );
> >-}
> >-/* 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.

Yeah, I just realized this when Jason mentioned the counter_32k on
OMAP.

So for next step, we may add something in timekeeping.c like
static struct clocksource *suspend_time_cs;
read and save its counter righer before entering and after getting
out of suspended state. And create a new struct which includes
all time suspend related flags, counters, pointers, make it as a
member of struct timekeeper. Comments?

Thanks,
Feng


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[John Stultz]

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 
---
  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 = 
+   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_delta.tv_sec = 0;
+   read_persistent_clock(_new);
  
  	clockevents_resume();

clocksource_resume();
  
  	write_seqlock_irqsave(>lock, flags);
  
-	if (timespec_compare(, _suspend_time) > 0) {

-   ts = timespec_sub(ts, timekeeping_suspend_time);
-   __timekeeping_inject_sleeptime(tk, );
-   }
-   /* 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

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

Signed-off-by: Feng Tang 
---
 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 = 
+   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_delta.tv_sec = 0;
+   read_persistent_clock(_new);
 
clockevents_resume();
clocksource_resume();
 
write_seqlock_irqsave(>lock, flags);
 
-   if (timespec_compare(, _suspend_time) > 0) {
-   ts = timespec_sub(ts, timekeeping_suspend_time);
-   __timekeeping_inject_sleeptime(tk, );
-   }
-   /* 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);
+   if ((clock->flags & CLOCK_SOURCE_SUSPEND_NOTSTOP) &&
+   cycle_now > clock->cycle_last) {
+
+   u64 max_cycles;
+   u32 mult = clock->mult;
+   u32 shift = clock->shift;
+
+   cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
+   /*
+* The system suspended time and the delta cycles may be very
+* long, so we can't call clocksource_cyc2ns() directly with
+* clocksource's default mult and shift to avoid overflow.
+*/
+   max_cycles = 1ULL << (63 - (ilog2(mult) + 1));
+   while (cycle_delta > max_cycles) {
+   max_cycles <<= 1;
+   mult >>= 1;
+   shift--;
+   }
+
+   nsec = clocksource_cyc2ns(cycle_delta, mult, shift);
+   ts_delta = ns_to_timespec(nsec);
+   } else if (timespec_compare(_new, _suspend_time) > 0)
+   ts_delta = timespec_sub(ts_new, timekeeping_suspend_time);
+
+   if (ts_delta.tv_sec >= 1)
+   __timekeeping_inject_sleeptime(tk, _delta);
+
+   /* Re-base the last cycle value */
+   clock->cycle_last = clock->read(clock);
tk->ntp_error = 0;
timekeeping_suspended = 0;
timekeeping_update(tk, false);
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

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

Signed-off-by: Feng Tang feng.t...@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);
+   if ((clock-flags  CLOCK_SOURCE_SUSPEND_NOTSTOP) 
+   cycle_now  clock-cycle_last) {
+
+   u64 max_cycles;
+   u32 mult = clock-mult;
+   u32 shift = clock-shift;
+
+   cycle_delta = (cycle_now - clock-cycle_last)  clock-mask;
+   /*
+* The system suspended time and the delta cycles may be very
+* long, so we can't call clocksource_cyc2ns() directly with
+* clocksource's default mult and shift to avoid overflow.
+*/
+   max_cycles = 1ULL  (63 - (ilog2(mult) + 1));
+   while (cycle_delta  max_cycles) {
+   max_cycles = 1;
+   mult = 1;
+   shift--;
+   }
+
+   nsec = clocksource_cyc2ns(cycle_delta, mult, shift);
+   ts_delta = ns_to_timespec(nsec);
+   } else if (timespec_compare(ts_new, timekeeping_suspend_time)  0)
+   ts_delta = timespec_sub(ts_new, timekeeping_suspend_time);
+
+   if (ts_delta.tv_sec = 1)
+   __timekeeping_inject_sleeptime(tk, ts_delta);
+
+   /* Re-base the last cycle value */
+   clock-cycle_last = clock-read(clock);
tk-ntp_error = 0;
timekeeping_suspended = 0;
timekeeping_update(tk, false);
-- 
1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[John Stultz]

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.t...@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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:
 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.

Thanks :)

 Signed-off-by: Feng Tang feng.t...@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.

Yeah, I just realized this when Jason mentioned the counter_32k on
OMAP.

So for next step, we may add something in timekeeping.c like
static struct clocksource *suspend_time_cs;
read and save its counter righer before entering and after getting
out of suspended state. And create a new struct which includes
all time suspend related flags, counters, pointers, make it as a
member of struct timekeeper. Comments?

Thanks,
Feng


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[John Stultz]

On 03/05/2013 02:38 PM, Feng Tang wrote:

On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:



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.

Yeah, I just realized this when Jason mentioned the counter_32k on
OMAP.

So for next step, we may add something in timekeeping.c like
static struct clocksource *suspend_time_cs;
read and save its counter righer before entering and after getting
out of suspended state. And create a new struct which includes
all time suspend related flags, counters, pointers, make it as a
member of struct timekeeper. Comments?
I'd maybe add it to the clocksource code rather then the timekeeper. 
Have a clocksource_nonstop_clock() accessor which returns a pointer to 
the highest rated clocksource in the clocksource list that has the 
nonstop flag (updating the pointer at registration time, rather then 
scanning the list every time).


That way if we want, we can later define clocksource_nonstop_clock() as 
null, and let the complier optimize out the extra complexity in the 
resume path if the arch doesn't support nonstop clocksource.


thanks
-john
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 4/4] timekeeping: utilize the suspend-nonstop clocksource to count suspended time

[Feng Tang]

On Tue, Mar 05, 2013 at 02:47:27PM +0800, John Stultz wrote:
 On 03/05/2013 02:38 PM, Feng Tang wrote:
 On Tue, Mar 05, 2013 at 02:27:34PM +0800, John Stultz wrote:
 
 
 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.
 Yeah, I just realized this when Jason mentioned the counter_32k on
 OMAP.
 
 So for next step, we may add something in timekeeping.c like
  static struct clocksource *suspend_time_cs;
 read and save its counter righer before entering and after getting
 out of suspended state. And create a new struct which includes
 all time suspend related flags, counters, pointers, make it as a
 member of struct timekeeper. Comments?
 I'd maybe add it to the clocksource code rather then the timekeeper.
 Have a clocksource_nonstop_clock() accessor which returns a pointer
 to the highest rated clocksource in the clocksource list that has
 the nonstop flag (updating the pointer at registration time, rather
 then scanning the list every time).

Yes, it's more natural to put it in clocksource code if we need to
pick and compare a best non-stop-tsc clocksource.

Thanks,
Feng


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/