From: Petr Mladek <pmladek@suse.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>,
linux-kernel@vger.kernel.org,
John Stultz <john.stultz@linaro.org>,
Xunlei Pang <pang.xunlei@linaro.org>,
Baolin Wang <baolin.wang@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tejun Heo <tj@kernel.org>,
Peter Hurley <peter@hurleysoftware.com>,
Vasily Averin <vvs@virtuozzo.com>, Joe Perches <joe@perches.com>
Subject: Re: [PATCH 0/2] printk, Add printk.clock kernel parameter [v2]
Date: Thu, 14 Jan 2016 13:52:38 +0100 [thread overview]
Message-ID: <20160114125238.GU731@pathway.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.11.1601131550410.3575@nanos>
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.
> 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.
Best Regards,
Petr
next prev parent reply other threads:[~2016-01-14 12:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 12:34 [PATCH 0/2] printk, Add printk.clock kernel parameter [v2] Prarit Bhargava
2016-01-13 12:34 ` [PATCH 1/2] kernel, timekeeping, add ktime_get_[boot|real|tai]_fast_ns functions Prarit Bhargava
2016-01-13 12:34 ` [PATCH 2/2] printk, Add printk.clock kernel parameter Prarit Bhargava
2016-01-13 13:45 ` [PATCH 0/2] printk, Add printk.clock kernel parameter [v2] Thomas Gleixner
2016-01-13 14:36 ` Prarit Bhargava
2016-01-13 17:28 ` Thomas Gleixner
2016-01-14 12:52 ` Petr Mladek [this message]
2016-01-14 14:39 ` Prarit Bhargava
2016-01-14 14:44 ` Thomas Gleixner
2016-01-21 16:09 ` Prarit Bhargava
2016-01-22 8:04 ` Thomas Gleixner
-- strict thread matches above, loose matches on Subject: below --
2016-01-13 12:34 Prarit Bhargava
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160114125238.GU731@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pang.xunlei@linaro.org \
--cc=peter@hurleysoftware.com \
--cc=prarit@redhat.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vvs@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.