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
next prev parent 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.