[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1601141543130.3575@nanos>
Date: Thu, 14 Jan 2016 15:44:23 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
cc: Prarit Bhargava <prarit@...hat.com>, linux-kernel@...r.kernel.org,
John Stultz <john.stultz@...aro.org>,
Xunlei Pang <pang.xunlei@...aro.org>,
Baolin Wang <baolin.wang@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Tejun Heo <tj@...nel.org>,
Peter Hurley <peter@...leysoftware.com>,
Vasily Averin <vvs@...tuozzo.com>,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH 0/2] printk, Add printk.clock kernel parameter [v2]
On Thu, 14 Jan 2016, Petr Mladek wrote:
> On Wed 2016-01-13 18:28:50, Thomas Gleixner wrote:
> > You can solve the whole business by changing the timestamp in printk_log to
> >
> > u64 mono;
> > u64 offset_real;
>
> This is not so easy because the structure is proceed by userspace tool,
> e.g. crash, see log_buf_kexec_setup(). We would need to update all
> the tools as well.
Fair enough.
> > and have a function which does:
> >
> > u64 ktime_get_log_ts(u64 *offset_real)
> > {
> > *offset_real = tk_core.timekeeper.offs_real;
> >
> > if (timekeeping_active)
> > return ktime_get_mono_fast_ns();
> > else
> > return local_clock();
> > }
>
> A solution would be to apply the offset_real immediately. I wonder if
> any tool expects the messages to be sorted by a monotonic clock. In
> fact, it might be useful to see that some messages are disordered
> against the real time, e.g. because of the leaf second.
Not only leap seconds, it's also settimeofday and NTP might make the wall time
jump under certain conditions.
Thanks,
tglx
Powered by blists - more mailing lists