All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Mark Salyzyn <salyzyn@android.com>,
	Petr Mladek <pmladek@suse.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [GIT pull] printk updates for 4.15
Date: Wed, 15 Nov 2017 09:04:02 +0100	[thread overview]
Message-ID: <20171115080402.gz5k3qzfaexucc3p@gmail.com> (raw)
In-Reply-To: <CA+55aFzAvSe9WjSgyUHns+Z3LbpMFWSU_uze0B8XTRzbnk3rVg@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > +/*
> > + * struct timestanps - Simultaneous mono/boot/real timestamps
> > + * @mono:      Monotonic timestamp
> > + * @boot:      Boottime timestamp
> > + * @real:      Realtime timestamp
> > + */
> 
> Side note: does anybody really wanr/need the boottime thing?
> 
> I can definitely understand why people want a monotonic clock (since
> ordering is meaningful). And at the same time, it's pretty obvious
> that wall clock is meaningful.
> 
> Who really wants that boot time thing when you have those two? I get
> the feeling hat nobody really wanted it, and it was just added for
> completeness.

IIRC there were some boot time optimization tools that used the boot-time relative 
timestamps to visualize and compare things - but I don't know whether they used 
the text-form timestamps or the binary log timestamp. (I suspect the former.)

> I don't think 'struct printk_log' is _that_ size sensitive, but it
> does seem to be a bad idea to add 8 bytes without having a good reason
> for it. The other times seem to have good reasons, not so much the
> boot one.

So I think when it comes to 'timing' and post-mortem log analysis, then redundancy 
of time sources is usually good. "When did this occur after bootup" is inherent in 
boot timestamps - and is usable even if the 'when did the system boot up' info is 
lost (got log-rotated away, or cannot be trusted, etc.).

It's admittedly a bit of a handwaving argument, because the timestamps _are_ 
redundant and can be completely eliminated on a properly run system with proper 
timekeeping and all log entries available, but in general this kind of redundancy 
does not feel actively bad to me. (In fact I'd argue that having such redundancy 
is one of the (few) advantages of binary log formats, because tools don't mind the 
visual clutter, so we might as well make use of it.)

Thanks,

	Ingo

  reply	other threads:[~2017-11-15  8:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13  9:36 [GIT pull] printk updates for 4.15 Thomas Gleixner
2017-11-14  1:18 ` Linus Torvalds
2017-11-14  2:48   ` Linus Torvalds
2017-11-14 10:03   ` Petr Mladek
2017-11-14 13:28     ` Prarit Bhargava
2017-11-14 15:56     ` Mark Salyzyn
2017-11-15  0:48       ` Sergey Senozhatsky
2017-11-14 17:20     ` Linus Torvalds
2017-11-14 20:21       ` Thomas Gleixner
2017-11-14 21:07         ` Linus Torvalds
2017-11-14 21:09           ` Thomas Gleixner
2017-11-14 21:16           ` Mark Salyzyn
2017-11-14 21:29             ` Linus Torvalds
2017-11-14 22:10               ` Mark Salyzyn
2017-11-14 22:37                 ` Linus Torvalds
2017-11-14 22:50                   ` Thomas Gleixner
2017-11-14 23:00                     ` Joe Perches
2017-11-14 23:00                     ` Linus Torvalds
2017-11-14 23:04                       ` Thomas Gleixner
2017-11-14 23:18                         ` Linus Torvalds
2017-11-14 23:22                           ` Thomas Gleixner
2017-11-15  0:00                     ` Linus Torvalds
2017-11-15  8:04                       ` Ingo Molnar [this message]
2017-11-15 16:26                       ` Mark Salyzyn
2017-11-15 17:42                         ` Linus Torvalds
2017-11-16  0:37                           ` Thomas Gleixner
2017-11-16  1:23                             ` John Stultz
2017-11-16  1:32                             ` Linus Torvalds
2017-11-16  7:12                               ` Thomas Gleixner
2017-11-18  0:26                                 ` Thomas Gleixner
2017-11-18  0:44                                   ` Linus Torvalds
2017-11-18  1:00                                     ` Thomas Gleixner
2017-11-20  6:20                                   ` Kevin Easton
2017-11-20  6:36                                     ` Linus Torvalds
2018-01-29 20:34                     ` Mark Salyzyn
2018-01-29 21:49                       ` Thomas Gleixner

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=20171115080402.gz5k3qzfaexucc3p@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=prarit@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=salyzyn@android.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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.