From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB1E0C4363D for ; Fri, 25 Sep 2020 09:51:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5EB7422211 for ; Fri, 25 Sep 2020 09:51:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="KaDIc5PG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728031AbgIYJvZ (ORCPT ); Fri, 25 Sep 2020 05:51:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:37556 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727819AbgIYJvZ (ORCPT ); Fri, 25 Sep 2020 05:51:25 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1601027483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vAi/aR75Ote0HPMVROUAFbJ3AhLP6tIxclhH8TKF+t8=; b=KaDIc5PGxlmicuM1zqhGsIeenrkfE+yDDAWMRNWxO/+b8qWd/zia8qly0OkG+xSjIXara4 mC7K5aNUxEsPOPMoMCyDhInpjy9C6Jb8jw7lQ24FyV7QOJxGZuG5lX89/4/yXxd0+Aw8sM gtz5dzMR2XvNrpqINizc0SFWncHlNfQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 298E8ACC2; Fri, 25 Sep 2020 09:51:23 +0000 (UTC) Date: Fri, 25 Sep 2020 11:51:21 +0200 From: Petr Mladek To: Mark Salyzyn Cc: John Ogness , Sergey Senozhatsky , Steven Rostedt , Linus Torvalds , Thomas Gleixner , Prarit Bhargava , Chunyan Zhang , Orson Zhai , Changki Kim , Sergey Senozhatsky , LKML Subject: Re: [PATCH 1/2] printk: Store all three timestamps Message-ID: <20200925095121.GN29288@alley> References: <20200923135617.27149-1-pmladek@suse.com> <20200923135617.27149-2-pmladek@suse.com> <87pn6cdtwa.fsf@jogness.linutronix.de> <20200924114952.GA29288@alley> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2020-09-24 10:07:57, Mark Salyzyn wrote: > I would hope for monotonic_raw, boottime and realtime as being the most > useful for most situations. > > [TL;DR] > > Currently kernel logs actually uses monotonic_raw (no timing clock > correction), not monotonic (timing correction). > > Whereas boot (timing clock adjusted, still monotonic) and realtime (timing > clock _and_ time adjusted, non monotonic), when we try to correlate to user > space is workable, but we will have troubles correlating monotonic (w.r.t. > monotonic_raw) clocks if used in user space. > > In Android we have the option of monotonic and realtime only right now for > the user space logger (which integrates logd, klogd and auditd, the later > two come from the kernel). I have bugs open to consider boottime, but it is > blocked on boottime availability from kernel space logging (this change). I > have another bug to consider switching the logger to monotonic_raw instead > of monotonic, to make it correlate better with existing kernel logs. But > alas a lot of resistance for phones switching to monotonic(_raw), the only > devices that chose monotonic(_raw) is everything else (google glass, > watches, ...). As such, phones, and the associated developers, will > continue to want realtime correlated in the kernel logs (yes, this change > too). > > realtime sucks for the first 10 seconds on Android, since phones generally > do not get their time correction until then from network resources, and > many of their rtc clocks are not adjustable, they store a correction factor > that does not get picked up from user space until userdata is mounted > (about 20 seconds in). But only kernel developers care about this first > part of boot, everything after that (and associated correlated kernel > interactions) are for user space folks. Thanks a lot for this detailed feedback. Just to be sure that I understand it correctly. You suggest to store three timestamps: local_clock(), boot and real clock. It makes sense to me. I just wonder if there might be any use case when the adjusted mono clock is needed or preferred over local_clock(). Best Regards, Petr