Re: [GIT pull] printk updates for 4.15

[Mark Salyzyn <salyzyn@android.com>]

On 11/14/2017 04:00 PM, Linus Torvalds 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?
"Android partners have asked for it". I have said no...

Maybe for completeness, but having it may straighten out a 
synchronization mess.

[TL;DR]

"If you have three watches, you will never know what time it is"(tm)

Android peripherals with embedded firmware (camera, sensor hub, etc) all 
are run synchronized to boottime. If the firmware logs any data and it 
is propagated, we run into issues trying to triage firmware, kernel and 
user space temporal activities as each is on a different timebase.

Android's logger cluster (logd) today can only be switched between 
CLOCK_REALTIME or CLOCK_MONOTONIC for its timebase. It tries to track 
the pair to merge content from all the sources. use is mixed: 
CLOCK_REALTIME is selected on phones/tablets, CLOCK_MONOTONIC is 
selected on watches. CLOCK_BOOTIME to make a trio of synchronized time 
sources is being requested.

We are blocked on introducing CLOCK_BOOTTIME as an option because it is 
difficult to discern between logging utilizing CLOCK_BOOTTIME or 
CLOCK_MONOTONIC based on incoming value alone (heuristics) so the 
infrastructure will change. Logging (in user space) the trio of 
timestamps is too costly (2.5us, currently CLOCK_BOOTTIME is not 
supplied by vdso, so is a syscall) and some sources will never report 
the trio. (I have patches that fix CLOCK_BOOTTIME in vdso being 
considered in the vdso-unification effort)

CLOCK_BOOTTIME and CLOCK_MONOTONIC represent an issue for continuity 
through a reboot or kernel crash. Stitching them together sometimes 
generates maniacal laughter. CLOCK_REALTIME is not set until a LTE 
connection is made, so we are effectively seeing CLOCK_BOOTTIME (or 
worse, some random offset) logging until later in the boot cycle. 
Currently kernel logs and atrace (kernel ftrace + a user merged 
component) are CLOCK_MONOTONIC.

I do not know if we will ever unify the timebases. Or select one 
(CLOCK_BOOTTIME has been suggested as the best choice). kernel 
supporting it, or the trio, in logd.auditd and logd.klogd threads would 
be a step towards a better and synchronized logging world though.

-- Mark