From: Mark Salyzyn <salyzyn@android.com>
To: Petr Mladek <pmladek@suse.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@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: Tue, 14 Nov 2017 07:56:52 -0800 [thread overview]
Message-ID: <b609e8ed-7317-81fe-876c-7687f7e5044c@android.com> (raw)
In-Reply-To: <20171114100336.uil744pxmbsawq63@pathway.suse.cz>
On 11/14/2017 02:03 AM, Petr Mladek wrote:
> On Mon 2017-11-13 17:18:33, Linus Torvalds wrote:
>> On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> Honestly, this just seems bogus to me, particularly since it's a single choice.
>>
>> The *sane* model would be to
>>
>> (a) continue to use the existing time that we always have
>> (local_clock()) in the printk timestamps, and don't confuse people
>> with the semantics of that field changing.
>>
>> (b) just emit a "synchronization printk" every once in a while, which
>> is obviously also using the same standard time source, but the line
>> actually _says_ what the other time sources are.
> This was actually the original approach by Mark Salyzyn, see
> https://lkml.kernel.org/r/20170720182505.9357-1-salyzyn@android.com
Thanks for the vote of confidence :-) but we were holding back re
spinning that set until the ability to switch the primary timestamp got
accepted. (we were to use U suffix for realtime, B for boottime etc to
designate them).
Printing the other timebases during major disruptions
(suspend/resume/etc) was needed for our battery monitoring analysis
tools, and we only used them as synchronization markers as a secondary
effect.
But we _also_ had Android partners asking if it was possible to switch
the primary (dmesg) timestamp to one of boottime or realtime to aid in
triaging temporal issues. Doing so in the tool was sometimes too
inaccurate (~+/-20ms) even with help sniffing the periodic
synchronization/disruption prints. Switching the timebase for dmesg gave
us roughly 1000 times more comparative time precision which helps
immensely when trying to correlate and order the sequence of events in
user space and kernel activities.
-- Mark
next prev parent reply other threads:[~2017-11-14 15:57 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 [this message]
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
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=b609e8ed-7317-81fe-876c-7687f7e5044c@android.com \
--to=salyzyn@android.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=prarit@redhat.com \
--cc=rostedt@goodmis.org \
--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.