From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755010AbdKNP5E (ORCPT ); Tue, 14 Nov 2017 10:57:04 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:40882 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752772AbdKNP45 (ORCPT ); Tue, 14 Nov 2017 10:56:57 -0500 X-Google-Smtp-Source: AGs4zMbG6J8y3BgDn/IcFUIJsVmjwm7Fz2AepS5k3NdbKoaalsChDuwSgu5xVmZyLIgZytZxhD0f/Q== Subject: Re: [GIT pull] printk updates for 4.15 To: Petr Mladek , Linus Torvalds Cc: Thomas Gleixner , LKML , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Andrew Morton , Prarit Bhargava , Sergey Senozhatsky , Steven Rostedt References: <20171114100336.uil744pxmbsawq63@pathway.suse.cz> From: Mark Salyzyn Message-ID: Date: Tue, 14 Nov 2017 07:56:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171114100336.uil744pxmbsawq63@pathway.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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