Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[John Stultz]

On Fri, Jan 6, 2017 at 6:39 PM, Joel Fernandes  wrote:
> Hi John,
>
> On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
>> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>>> This boot clock can be used as a tracing clock and will account for
>>> suspend time.
>>>
>>> To keep it NMI safe since we're accessing from tracing, we're not using a
>>> separate timekeeper with updates to monotonic clock and boot offset
>>> protected with seqlocks. This has the following minor side effects:
>>>
>>> (1) Its possible that a timestamp be taken after the boot offset is updated
>>> but before the timekeeper is updated. If this happens, the new boot offset
>>> is added to the old timekeeping making the clock appear to update slightly
>>> earlier:
>>>CPU 0CPU 1
>>>timekeeping_inject_sleeptime64()
>>>__timekeeping_inject_sleeptime(tk, delta);
>>> timestamp();
>>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>>
>>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>>> partially updated.  Since the tk->offs_boot update is a rare event, this
>>> should be a rare occurrence which postprocessing should be able to handle.
>>>
>>> Cc: Steven Rostedt 
>>> Cc: Thomas Gleixner 
>>> Cc: John Stultz 
>>> Cc: Ingo Molnar 
>>> Signed-off-by: Joel Fernandes 
>>
>> Hey Joel,
>>   Hope you had a good new years! I was queuing this up for testing,
>
> Thanks, yes I had a great new years, hope you did too.
>
>> and the patch set no longer applies (to v4.10-rc2). Can you respin it
>> and resend it?
>
> Actually these patches are already in 4.10-rc2.

Ha! Well, apologies for missing that over the holidays.

Sorry for the noise.
-john

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[John Stultz]

On Fri, Jan 6, 2017 at 6:39 PM, Joel Fernandes  wrote:
> Hi John,
>
> On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
>> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>>> This boot clock can be used as a tracing clock and will account for
>>> suspend time.
>>>
>>> To keep it NMI safe since we're accessing from tracing, we're not using a
>>> separate timekeeper with updates to monotonic clock and boot offset
>>> protected with seqlocks. This has the following minor side effects:
>>>
>>> (1) Its possible that a timestamp be taken after the boot offset is updated
>>> but before the timekeeper is updated. If this happens, the new boot offset
>>> is added to the old timekeeping making the clock appear to update slightly
>>> earlier:
>>>CPU 0CPU 1
>>>timekeeping_inject_sleeptime64()
>>>__timekeeping_inject_sleeptime(tk, delta);
>>> timestamp();
>>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>>
>>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>>> partially updated.  Since the tk->offs_boot update is a rare event, this
>>> should be a rare occurrence which postprocessing should be able to handle.
>>>
>>> Cc: Steven Rostedt 
>>> Cc: Thomas Gleixner 
>>> Cc: John Stultz 
>>> Cc: Ingo Molnar 
>>> Signed-off-by: Joel Fernandes 
>>
>> Hey Joel,
>>   Hope you had a good new years! I was queuing this up for testing,
>
> Thanks, yes I had a great new years, hope you did too.
>
>> and the patch set no longer applies (to v4.10-rc2). Can you respin it
>> and resend it?
>
> Actually these patches are already in 4.10-rc2.

Ha! Well, apologies for missing that over the holidays.

Sorry for the noise.
-john

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[Joel Fernandes]

Hi John,

On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>> This boot clock can be used as a tracing clock and will account for
>> suspend time.
>>
>> To keep it NMI safe since we're accessing from tracing, we're not using a
>> separate timekeeper with updates to monotonic clock and boot offset
>> protected with seqlocks. This has the following minor side effects:
>>
>> (1) Its possible that a timestamp be taken after the boot offset is updated
>> but before the timekeeper is updated. If this happens, the new boot offset
>> is added to the old timekeeping making the clock appear to update slightly
>> earlier:
>>CPU 0CPU 1
>>timekeeping_inject_sleeptime64()
>>__timekeeping_inject_sleeptime(tk, delta);
>> timestamp();
>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>
>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>> partially updated.  Since the tk->offs_boot update is a rare event, this
>> should be a rare occurrence which postprocessing should be able to handle.
>>
>> Cc: Steven Rostedt 
>> Cc: Thomas Gleixner 
>> Cc: John Stultz 
>> Cc: Ingo Molnar 
>> Signed-off-by: Joel Fernandes 
>
> Hey Joel,
>   Hope you had a good new years! I was queuing this up for testing,

Thanks, yes I had a great new years, hope you did too.

> and the patch set no longer applies (to v4.10-rc2). Can you respin it
> and resend it?

Actually these patches are already in 4.10-rc2.

Regards,
Joel

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[Joel Fernandes]

Hi John,

On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>> This boot clock can be used as a tracing clock and will account for
>> suspend time.
>>
>> To keep it NMI safe since we're accessing from tracing, we're not using a
>> separate timekeeper with updates to monotonic clock and boot offset
>> protected with seqlocks. This has the following minor side effects:
>>
>> (1) Its possible that a timestamp be taken after the boot offset is updated
>> but before the timekeeper is updated. If this happens, the new boot offset
>> is added to the old timekeeping making the clock appear to update slightly
>> earlier:
>>CPU 0CPU 1
>>timekeeping_inject_sleeptime64()
>>__timekeeping_inject_sleeptime(tk, delta);
>> timestamp();
>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>
>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>> partially updated.  Since the tk->offs_boot update is a rare event, this
>> should be a rare occurrence which postprocessing should be able to handle.
>>
>> Cc: Steven Rostedt 
>> Cc: Thomas Gleixner 
>> Cc: John Stultz 
>> Cc: Ingo Molnar 
>> Signed-off-by: Joel Fernandes 
>
> Hey Joel,
>   Hope you had a good new years! I was queuing this up for testing,

Thanks, yes I had a great new years, hope you did too.

> and the patch set no longer applies (to v4.10-rc2). Can you respin it
> and resend it?

Actually these patches are already in 4.10-rc2.

Regards,
Joel

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[John Stultz]

On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
> This boot clock can be used as a tracing clock and will account for
> suspend time.
>
> To keep it NMI safe since we're accessing from tracing, we're not using a
> separate timekeeper with updates to monotonic clock and boot offset
> protected with seqlocks. This has the following minor side effects:
>
> (1) Its possible that a timestamp be taken after the boot offset is updated
> but before the timekeeper is updated. If this happens, the new boot offset
> is added to the old timekeeping making the clock appear to update slightly
> earlier:
>CPU 0CPU 1
>timekeeping_inject_sleeptime64()
>__timekeeping_inject_sleeptime(tk, delta);
> timestamp();
>timekeeping_update(tk, TK_CLEAR_NTP...);
>
> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
> partially updated.  Since the tk->offs_boot update is a rare event, this
> should be a rare occurrence which postprocessing should be able to handle.
>
> Cc: Steven Rostedt 
> Cc: Thomas Gleixner 
> Cc: John Stultz 
> Cc: Ingo Molnar 
> Signed-off-by: Joel Fernandes 

Hey Joel,
  Hope you had a good new years! I was queuing this up for testing,
and the patch set no longer applies (to v4.10-rc2). Can you respin it
and resend it?

thanks
-john

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[John Stultz]

On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
> This boot clock can be used as a tracing clock and will account for
> suspend time.
>
> To keep it NMI safe since we're accessing from tracing, we're not using a
> separate timekeeper with updates to monotonic clock and boot offset
> protected with seqlocks. This has the following minor side effects:
>
> (1) Its possible that a timestamp be taken after the boot offset is updated
> but before the timekeeper is updated. If this happens, the new boot offset
> is added to the old timekeeping making the clock appear to update slightly
> earlier:
>CPU 0CPU 1
>timekeeping_inject_sleeptime64()
>__timekeeping_inject_sleeptime(tk, delta);
> timestamp();
>timekeeping_update(tk, TK_CLEAR_NTP...);
>
> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
> partially updated.  Since the tk->offs_boot update is a rare event, this
> should be a rare occurrence which postprocessing should be able to handle.
>
> Cc: Steven Rostedt 
> Cc: Thomas Gleixner 
> Cc: John Stultz 
> Cc: Ingo Molnar 
> Signed-off-by: Joel Fernandes 

Hey Joel,
  Hope you had a good new years! I was queuing this up for testing,
and the patch set no longer applies (to v4.10-rc2). Can you respin it
and resend it?

thanks
-john

[PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[Joel Fernandes]

This boot clock can be used as a tracing clock and will account for
suspend time.

To keep it NMI safe since we're accessing from tracing, we're not using a
separate timekeeper with updates to monotonic clock and boot offset
protected with seqlocks. This has the following minor side effects:

(1) Its possible that a timestamp be taken after the boot offset is updated
but before the timekeeper is updated. If this happens, the new boot offset
is added to the old timekeeping making the clock appear to update slightly
earlier:
   CPU 0CPU 1
   timekeeping_inject_sleeptime64()
   __timekeeping_inject_sleeptime(tk, delta);
timestamp();
   timekeeping_update(tk, TK_CLEAR_NTP...);

(2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
partially updated.  Since the tk->offs_boot update is a rare event, this
should be a rare occurrence which postprocessing should be able to handle.

Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Ingo Molnar 
Signed-off-by: Joel Fernandes 
---
 include/linux/timekeeping.h |  1 +
 kernel/time/timekeeping.c   | 29 +
 2 files changed, 30 insertions(+)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 09168c5..361f8bf 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -249,6 +249,7 @@ static inline u64 ktime_get_raw_ns(void)
 
 extern u64 ktime_get_mono_fast_ns(void);
 extern u64 ktime_get_raw_fast_ns(void);
+extern u64 ktime_get_boot_fast_ns(void);
 
 /*
  * Timespec interfaces utilizing the ktime based ones
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 37dec7e..b2286e9 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -425,6 +425,35 @@ u64 ktime_get_raw_fast_ns(void)
 }
 EXPORT_SYMBOL_GPL(ktime_get_raw_fast_ns);
 
+/**
+ * ktime_get_boot_fast_ns - NMI safe and fast access to boot clock.
+ *
+ * To keep it NMI safe since we're accessing from tracing, we're not using a
+ * separate timekeeper with updates to monotonic clock and boot offset
+ * protected with seqlocks. This has the following minor side effects:
+ *
+ * (1) Its possible that a timestamp be taken after the boot offset is updated
+ * but before the timekeeper is updated. If this happens, the new boot offset
+ * is added to the old timekeeping making the clock appear to update slightly
+ * earlier:
+ *CPU 0CPU 1
+ *timekeeping_inject_sleeptime64()
+ *__timekeeping_inject_sleeptime(tk, delta);
+ * timestamp();
+ *timekeeping_update(tk, TK_CLEAR_NTP...);
+ *
+ * (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
+ * partially updated.  Since the tk->offs_boot update is a rare event, this
+ * should be a rare occurrence which postprocessing should be able to handle.
+ */
+u64 notrace ktime_get_boot_fast_ns(void)
+{
+   struct timekeeper *tk = _core.timekeeper;
+
+   return (ktime_get_mono_fast_ns() + ktime_to_ns(tk->offs_boot));
+}
+EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);
+
 /* Suspend-time cycles value for halted fast timekeeper. */
 static cycle_t cycles_at_suspend;
 
-- 
2.8.0.rc3.226.g39d4020

[PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[Joel Fernandes]

This boot clock can be used as a tracing clock and will account for
suspend time.

To keep it NMI safe since we're accessing from tracing, we're not using a
separate timekeeper with updates to monotonic clock and boot offset
protected with seqlocks. This has the following minor side effects:

(1) Its possible that a timestamp be taken after the boot offset is updated
but before the timekeeper is updated. If this happens, the new boot offset
is added to the old timekeeping making the clock appear to update slightly
earlier:
   CPU 0CPU 1
   timekeeping_inject_sleeptime64()
   __timekeeping_inject_sleeptime(tk, delta);
timestamp();
   timekeeping_update(tk, TK_CLEAR_NTP...);

(2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
partially updated.  Since the tk->offs_boot update is a rare event, this
should be a rare occurrence which postprocessing should be able to handle.

Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Ingo Molnar 
Signed-off-by: Joel Fernandes 
---
 include/linux/timekeeping.h |  1 +
 kernel/time/timekeeping.c   | 29 +
 2 files changed, 30 insertions(+)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 09168c5..361f8bf 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -249,6 +249,7 @@ static inline u64 ktime_get_raw_ns(void)
 
 extern u64 ktime_get_mono_fast_ns(void);
 extern u64 ktime_get_raw_fast_ns(void);
+extern u64 ktime_get_boot_fast_ns(void);
 
 /*
  * Timespec interfaces utilizing the ktime based ones
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 37dec7e..b2286e9 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -425,6 +425,35 @@ u64 ktime_get_raw_fast_ns(void)
 }
 EXPORT_SYMBOL_GPL(ktime_get_raw_fast_ns);
 
+/**
+ * ktime_get_boot_fast_ns - NMI safe and fast access to boot clock.
+ *
+ * To keep it NMI safe since we're accessing from tracing, we're not using a
+ * separate timekeeper with updates to monotonic clock and boot offset
+ * protected with seqlocks. This has the following minor side effects:
+ *
+ * (1) Its possible that a timestamp be taken after the boot offset is updated
+ * but before the timekeeper is updated. If this happens, the new boot offset
+ * is added to the old timekeeping making the clock appear to update slightly
+ * earlier:
+ *CPU 0CPU 1
+ *timekeeping_inject_sleeptime64()
+ *__timekeeping_inject_sleeptime(tk, delta);
+ * timestamp();
+ *timekeeping_update(tk, TK_CLEAR_NTP...);
+ *
+ * (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
+ * partially updated.  Since the tk->offs_boot update is a rare event, this
+ * should be a rare occurrence which postprocessing should be able to handle.
+ */
+u64 notrace ktime_get_boot_fast_ns(void)
+{
+   struct timekeeper *tk = _core.timekeeper;
+
+   return (ktime_get_mono_fast_ns() + ktime_to_ns(tk->offs_boot));
+}
+EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns);
+
 /* Suspend-time cycles value for halted fast timekeeper. */
 static cycle_t cycles_at_suspend;
 
-- 
2.8.0.rc3.226.g39d4020