Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp974929pxk; Fri, 25 Sep 2020 02:55:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkojOSqiRtzXSzdz8gYL3rBtiNqgfajdjb7zNPTwg1UFXT4bUFhtKY+N6Wm7xYIhSh1IMm X-Received: by 2002:a17:906:d936:: with SMTP id rn22mr1916856ejb.4.1601027731382; Fri, 25 Sep 2020 02:55:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601027731; cv=none; d=google.com; s=arc-20160816; b=J9jRtw8OqXYvpL8JmuoLzQ1rW7PAUyYO1kWZtvKZljwhqbzd5HwWHNZrlqwmWdUad4 Aaks6WAb0XyqlKaKkCKDBDZT8Gg9alLfC3fZEwE1brYGY4Bq1N7IOzU+U2zbSsReIis5 14ywQ16Jqg3qF/4zJ8VWEerrcb/FDLWoDG4aRyzvQlKz51UOE14Aaqm1w59tkiITTITY 5QSf8QPFCbvM9TDW7aTBG5mNWHtJ+kqpc+iksZZ5SgMDRaml9LyaKDYt1B8bo5soYJfo mc22D+9bC0LlmWrgyblG0mbTBfFe9YS5sbyLcuADcaPeexORRJxhhLBYDvJWRKxrKt8n ZesQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=vAi/aR75Ote0HPMVROUAFbJ3AhLP6tIxclhH8TKF+t8=; b=BydeC6RPBi8KKOkCv38QXKeXZrOtte86uu5llHdWDcUYwksILGC/PGaEK9rGRHZkfY yAElwHWr4LCKdXvVKni973R3WU0snCiTVxC/Luz75WcCiCl/s3t6ItefndcXV/5lVdxL zEnExogZhfCTnytOckIi8uDkUmyTnKNOx1u0icEmxiJTaPp2Jh8gMlqrmC4uZw85XeE3 OBVFTFsHzXT5Sjdlt+OfG+1ZygM62HfqmRdVuJBV0P65juU5NmL0qn8OAYfP2L/tmOyQ uLxJmkQOHLD5j+HQeRZme9So9+zpfE2GNVrY+I118uFjPGtz2H8tsQd5209XmWydlGKp gDuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=KaDIc5PG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw15si1399966edb.299.2020.09.25.02.55.08; Fri, 25 Sep 2020 02:55:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=KaDIc5PG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727966AbgIYJvZ (ORCPT + 99 others); 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