[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3023e33-149a-e741-b937-1244797ef9c2@android.com>
Date: Wed, 15 Nov 2017 08:26:56 -0800
From: Mark Salyzyn <salyzyn@...roid.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Cc: Petr Mladek <pmladek@...e.com>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Prarit Bhargava <prarit@...hat.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [GIT pull] printk updates for 4.15
On 11/14/2017 04:00 PM, Linus Torvalds wrote:
> On Tue, Nov 14, 2017 at 2:50 PM, Thomas Gleixner <tglx@...utronix.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
Powered by blists - more mailing lists