Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp361492pxa; Tue, 11 Aug 2020 05:06:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqPRdu7YNYrFkxqMx1vrlVr3BaJSa290GGT+TKemMbYXmaBq25cqir/rVHRkq0xWXN8qJj X-Received: by 2002:a17:906:d786:: with SMTP id pj6mr26467242ejb.261.1597147603419; Tue, 11 Aug 2020 05:06:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597147603; cv=none; d=google.com; s=arc-20160816; b=RuQKW7GCbrUUySMPgsArHz9WDeutxl1OtEdk3mt8LsWAXLPhr79KJIVt6oyFIPgZsR O1jS2J/H8U2o4ryUnockA1AMDngluIR5osikfYcQFEHat0VVcWFqM4uxRkVmBNfRIdgm +oRX5WKsfNltqu6peVQOj+exR3/SMUT2xpEL9U3sXVSOpRo+r1G0fK3fJ6166OhGD8Eu FkFRLZj4GiAqzhVz0FvgWK7RmWTZPR8HHiqPjfNyWg8iT5QZMnw1/JB8EqZVNuWOfh4+ 4wrKcYM8TimTs6xNYaBcFL12tBjl3kRaFIJLQOghQ+f3gbGdvfPxoada4VwYzdw55dhp DNMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=+dK8WotNUMQfxKOXF2AcU6HDIE1VmkJ89HicTROKHMo=; b=Y9nL98364fyjcjYXppLrJmkVW/27YO1cbotyhNyq6XsdqJuyqf+/TohRDbb96EXPoH F+g+DIilLUrtyPC/kv9pZABMChQA0hX0XKO8tAnXF80JGqsX0FDKlIvFRBtiAMPm5Ugx 1j4cNKQXVtxwVJ6hXuC7TgGjWAIZLQdytsENu8FtkULOGNzGtvJhv7BUkkhAdM9YVJz8 z1zWhP+J0FwPSlCoiSS9stM+tRDKRNzO1ecpmlNp/DMdlkEIpj7bcBw+JDcY5wQMqApW SuYq09qtBeYO0swMgMEk1DfF3AtZRDhH/Cw2qe7Md+LTLSSFpeJwgHlxYFqL87iVdzDP mbtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=mvVp9Vol; dkim=neutral (no key) header.i=@vger.kernel.org; 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=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q2si13065718edj.526.2020.08.11.05.06.19; Tue, 11 Aug 2020 05:06:43 -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=@linutronix.de header.s=2020 header.b=mvVp9Vol; dkim=neutral (no key) header.i=@vger.kernel.org; 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=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728791AbgHKMF2 (ORCPT + 99 others); Tue, 11 Aug 2020 08:05:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728790AbgHKMFQ (ORCPT ); Tue, 11 Aug 2020 08:05:16 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35156C06174A for ; Tue, 11 Aug 2020 05:05:15 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1597147513; 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=+dK8WotNUMQfxKOXF2AcU6HDIE1VmkJ89HicTROKHMo=; b=mvVp9Vol15NrOMBy1pOO9HLG4HsFrbYsf3ARXETIr4zrdsOqiDYATiUZkluYMGgqNdeLt2 LahmEMEEFl3KWxB8FhNyshFsOCJZsM++I7I5WFPQPbT/DOn51RoI5lXBGAFIstn9V0VXHZ nuoIGiy7RvD9rLFw8a2qsZDYYcY2vXned40evQYhb6XeDLQ3m3o12E/0CBU9gsjuk8lyiD 4h5+Bt0IOgwgddhhray4vufb42rj6zcMbq+MjZsmezdPaMDlA1WMG9kkcmQdrFwzUYHBjA MzBiUOEAwtAXcW8aCoYoRCj6xuZ/rvfNHgqyrZ+THcqt0b+XdEi0EGUc86xnyg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1597147513; 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=+dK8WotNUMQfxKOXF2AcU6HDIE1VmkJ89HicTROKHMo=; b=nXG5qTaYy1OOViAbbTSHHHexYsZzlHPXAXraJ7gk+05OyrnRF3CMuQXgK2oSuQJIKWNq3x 6woX2fWJ6PFjpaDw== To: Petr Mladek , Orson Zhai Cc: Prarit Bhargava , Dave Young , Baoquan He , Vivek Goyal , Sergey Senozhatsky , Steven Rostedt , John Stultz , Stephen Boyd , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, zhang.lyra@gmail.com, ruifeng.zhang1@unisoc.com, cixi.geng1@unisoc.com, Orson Zhai , Pavel Tatashin , Steven Sistare , Dominique Martinet , Jon DeVree , Salvatore Bonaccorso , John Ogness Subject: Re: [RFC PATCH] printk: Change timestamp to triplet as mono, boot and real In-Reply-To: <20200811094413.GA12903@alley> References: <1597120822-11999-1-git-send-email-orsonzhai@gmail.com> <20200811094413.GA12903@alley> Date: Tue, 11 Aug 2020 14:05:12 +0200 Message-ID: <87zh7175hj.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Petr Mladek writes: > On Tue 2020-08-11 12:40:22, Orson Zhai wrote: >> This is an updated version which comes from patch [1] written by Thomas >> and suggestion [2] about VMCORE_INFO given by Linus. All of that want's to be properly distangled into seperate patches. >> This patch has been tested in qemu-x86-system. One problem is the timestamp >> in kernel log will be printed [ 0.000000] for longer time than before. > > This would be a regression. People put huge effort into having early boot > timestamps, see > https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatashin@oracle.com/ > Adding some active people from this patchset into CC. > > I wonder if we could have these early timestamps also in the mono > clock. Not really. timekeeping init happens way after the early TSC (or whatever clock) is registered as sched_clock(). And there is no realistic way to move timekeeping init earlier. What we could do instead is to utilize sched_clock() up to the point where timekeeping becomes available and ensure that monotonic time is not jumping backwards vs. sched_clock() when switching over. For this early boot phase, clock realtime timestamps would be invalid of course and they can stay invalid even after timekeeping is initialized on systems where the RTC is not available in the early boot process. > At least "crash" tool would need an update anyway. AFAIK, it checks > the size of struct printk_log and refuses to read it when it changes. > > It means that the hack with VMCOREINFO_FIELD_OFFSET probably is not > needed because we would need to update the crashdump-related tools anyway. > > Well, the timing is good. We are about to switch the printk ring > buffer into a lockless one. It requires updating the crashdump tools > as well. We could do this at the same time. The lockless ring buffer > already is in linux-next. It is aimed for 5.10 or 5.11. ... > It would be great to synchronize all these changes changes of the > printk log buffer structures. I agree that having one update is a good thing, but pretty please can we finally make progress with this and not create yet another dependency? Thanks, tglx