Re: [RFC patch 3/7] printk: Use clock MONOTONIC for timestamps

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

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