lkml.org 
[lkml]   [2017]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC patch 3/7] printk: Use clock MONOTONIC for timestamps
Hello Thomas,

On (11/15/17 19:15), Thomas Gleixner wrote:
> local_clock() cannot be reliably correlated to CLOCK_MONOTONIC, which is
> used by user space, e.g. systemd, to create correlation timestamps.
>
> There are multiple reasons:
>
> - CLOCK_MONOTONIC is NTP adjusted, local_clock() not. Depending on the
> calibration accuracy and uptime significant drift can be observed.
>
> - CLOCK_MONOTONIC does not advance across suspend/resume for historical
> reasons. local_clock() might or might not depending on the properties of
> the underlying hardware counter.
>
> Use the NMI safe accessor to clock MONOTONIC instead of local_clock(). The
> access might be slower than local_clock(), but printk is not such a
> performance critical hotpath that it matters.
>
> Visible change:
>
> The early boot timestamps are jiffies based longer than with local_clock()
> depending on the platform. During suspend/resume the timestamp may become
> stale when the underlying clocksource hardware is not flagged with
> CLOCKSOURCE_SUSPEND_ACCESS_OK.
>
> A horrible follow up patch demonstrates how that could be mitigated.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> kernel/printk/printk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>

a silly nitpick,

I suppose we can do

-#include <linux/sched/clock.h>
+#include <linux/timekeeping.h>

-ss

\
 
 \ /
  Last update: 2017-11-16 08:59    [W:0.112 / U:1.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site