lkml.org 
[lkml]   [2017]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT pull] printk updates for 4.15

* 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

\
 
 \ /
  Last update: 2017-11-15 09:04    [W:0.150 / U:4.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site