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