public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Petr Mladek <pmladek@suse.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Prarit Bhargava <prarit@redhat.com>,
	Mark Salyzyn <salyzyn@android.com>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	Orson Zhai <orsonzhai@gmail.com>,
	Changki Kim <changki.kim@samsung.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH 1/2] printk: Store all three timestamps
Date: Thu, 24 Sep 2020 00:18:53 +0206	[thread overview]
Message-ID: <87pn6cdtwa.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20200923135617.27149-2-pmladek@suse.com>

On 2020-09-23, Petr Mladek <pmladek@suse.com> wrote:
> printk() historically shows the timestamps from the monotonic clock.

printk() uses the local clock, not the monotonic clock.

> It is fast, available early during boot, in any context, and even
> without using any lock.
>
> There are repeated requests [1][2][3] to show the timestamps from other
> clocks. The main motivation is to make it easier to correlate the kernel
> and userspace logs. Where userspace logs usually use the real time
> clock.
>
> Unfortunately, it is not possible to simply replace the default clock.
> Userspace tools, like journalctl, dmesg, expect to get the timestamps
> from the mono via /dev/kmsg interface or syslog syscall [4].
> Also administrators would be confused when logs from different
> systems use different clocks depending on kernel version or
> build option [5].
>
> As a result, the mono clock has to stay as the default clock
> and has to be used in the current user interfaces.

Actually this series is changing the default clock from local to
monotonic. I for one welcome this change (and wish ftrace would do it as
well), but it is a change.

> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 1560649cbd35..0ed8901916f4 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -520,10 +522,10 @@ static int log_store(u32 caller_id, int facility, int level,
>  	r.info->facility = facility;
>  	r.info->level = level & 7;
>  	r.info->flags = flags & 0x1f;
> -	if (ts_nsec > 0)
> -		r.info->ts_nsec = ts_nsec;
> +	if (ts)
> +		r.info->ts = *ts;
>  	else
> -		r.info->ts_nsec = local_clock();
> +		ktime_get_fast_timestamps(&r.info->ts);

I am wondering if we still want to keep the local_clock() as well (and
as the default). ftrace also uses it by default, which means traces and
printk logs could be coordinated by default until now.

The two clocks can vary quite a bit. I have a laptop where the local
clock drifts away from monotonic at about 50us per second.

> diff --git a/kernel/printk/printk_ringbuffer.h b/kernel/printk/printk_ringbuffer.h
> index 0adaa685d1ca..09082c8472d3 100644
> --- a/kernel/printk/printk_ringbuffer.h
> +++ b/kernel/printk/printk_ringbuffer.h
> @@ -14,7 +15,7 @@
>   */
>  struct printk_info {
>  	u64	seq;		/* sequence number */
> -	u64	ts_nsec;	/* timestamp in nanoseconds */
> +	struct ktime_timestamps ts; /* timestamps */
>  	u16	text_len;	/* length of text message */
>  	u8	facility;	/* syslog facility */
>  	u8	flags:5;	/* internal record flags */

If we wanted to keep the local clock, should the local clock be a part
of struct ktime_timestamps? Or should struct printk_info maintain that
separately (either as @ts_nsec or @ts_local or whatever).

John Ogness

  reply	other threads:[~2020-09-23 22:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 13:56 [RFC 0/2] printk: Add more metadata for each record Petr Mladek
2020-09-23 13:56 ` [PATCH 1/2] printk: Store all three timestamps Petr Mladek
2020-09-23 22:12   ` John Ogness [this message]
2020-09-24  1:45     ` Sergey Senozhatsky
2020-09-24 11:49     ` Petr Mladek
     [not found]       ` <CAJ-C09hqwOJhSXx1h40q96xhNZFXxP6dUVfjUQZpO4ZhOMZLbQ@mail.gmail.com>
2020-09-25  9:51         ` Petr Mladek
2020-09-24  0:00   ` John Ogness
2020-09-24 10:37     ` Petr Mladek
2020-09-23 13:56 ` [RFC 2/2] printk: Add more information about the printk caller Petr Mladek
2020-09-24  1:40   ` Sergey Senozhatsky
2020-09-24 11:58     ` Petr Mladek
2020-09-24  2:17   ` Sergey Senozhatsky
2020-09-24  8:23     ` John Ogness
2020-09-24 13:26       ` Petr Mladek
2020-09-24 13:06     ` Petr Mladek
2020-09-24  4:24   ` Ahmed S. Darwish
2020-09-24 12:53     ` Petr Mladek
2020-09-24 13:38       ` Petr Mladek
2020-09-25  0:54         ` Sergey Senozhatsky
2020-09-25 10:20           ` Petr Mladek
2020-10-21 11:48   ` 김창기

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=87pn6cdtwa.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=changki.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=orsonzhai@gmail.com \
    --cc=pmladek@suse.com \
    --cc=prarit@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=salyzyn@android.com \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=zhang.lyra@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox