Re: [GIT pull] printk updates for 4.15

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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