From patchwork Mon Jul 22 10:33:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 169361 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp7351076ilk; Mon, 22 Jul 2019 03:33:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxAEsNPyaPSTMGxgmT8LWpYWy7KyM7NnXxaEZ7oOZ5pHDJu1JYP/fskLNjhiLSyy8tVsZWr X-Received: by 2002:a63:181:: with SMTP id 123mr72711085pgb.63.1563791623814; Mon, 22 Jul 2019 03:33:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563791623; cv=none; d=google.com; s=arc-20160816; b=ez/2bq675KroEqBUyoNVxvQjgEWG7swRjTCb2bEVhYo7aZg4VZCc7ckQjVMoATa9iv TMYEqfPCQa0/fVvUdWOgXy9hDhZNaYTGtiPPZ/fr7kiMZCckxCqrTq96AGTzCPqHS/rl cqPyIptpDQoPpbrQiW4fmSH6npXQtOWP63DZV3nnfRw8kiikkpLBLX7I397PnuESRZNs fa2mlXZdfPz6Vc4wrGqSZUM1t5RHBqJ2AOhE/N6kCYC0Zww6k9pD5RS1YFLbXG5rE6NP mO+CR+90HdaKT5H43fw58sgavg77CHQiSqeU7zcd9UOmFtRV5A+MAKfa0rSZJXAJzVnk DMcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ut0oUgGzPWm0p0xXena5lQMdwxyeBB/x1iT+f4bDjP8=; b=rMFDjDxAdVGoHBfBMlu3pr23UQplSaIvjvJ/TB0PIDZvAMbkS3KrfpPIpD2wG7fhuu UlPYQeRPTKd6GHugH9bWrN9ixq6nTK+XOR9+ik7253MUW9byEJtkAaFwA3G0pgVvhTNa 46csMqUjVs75V2CAu8CO2kb9EuZgJjIz3lShxeEyPjlMi7NVNZ7ePCwHYQm25J/LMNuP FUB2RCGPmFBFRkQvKAuzNMLCzAeS4rsXCs1hScNgWc9nuAIvQTaQXwykx8dihzj9CX6X XYmnZbRuF4ziJ+ERzvLxlg+FUtjRGWCEFniayjHasRXXUDm2o1OzGS4e7n1i6JJuj7m2 +6qA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i71si7884479pge.3.2019.07.22.03.33.43; Mon, 22 Jul 2019 03:33:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728508AbfGVKdl (ORCPT + 29 others); Mon, 22 Jul 2019 06:33:41 -0400 Received: from foss.arm.com ([217.140.110.172]:35402 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726120AbfGVKdl (ORCPT ); Mon, 22 Jul 2019 06:33:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E54728; Mon, 22 Jul 2019 03:33:40 -0700 (PDT) Received: from filthy-habits.cambridge.arm.com (filthy-habits.cambridge.arm.com [10.1.197.61]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1E90F3F71A; Mon, 22 Jul 2019 03:33:39 -0700 (PDT) From: Marc Zyngier To: Thomas Gleixner , John Stultz , Pavel Tatashin , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Will Deacon , Catalin Marinas , Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/3] arm64: Allow early timestamping of kernel log Date: Mon, 22 Jul 2019 11:33:27 +0100 Message-Id: <20190722103330.255312-1-marc.zyngier@arm.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org So far, we've let the arm64 kernel start its meaningful time stamping of the kernel log pretty late, which is caused by sched_clock() being initialised rather late compared to other architectures. Pavel Tatashin proposed[1] to move the initialisation of sched_clock much earlier, which I had objections to. The reason for initialising sched_clock late is that a number of systems have broken counters, and we need to apply all kind of terrifying workarounds to avoid time going backward on the affected platforms. Being able to identify the right workaround comes pretty late in the kernel boot, and providing an unreliable sched_clock, even for a short period of time, isn't an appealing prospect. To address this, I'm proposing that we allow an architecture to chose to (1) divorce time stamping and sched_clock during the early phase of booting, and (2) inherit the time stamping clock as the new epoch the first time a sched_sched clock gets registered. (1) would allow arm64 to provide a time stamping clock, however unreliable it might be, while (2) would allow sched_clock to provide time stamps that are continuous with the time-stamping clock. The last patch in the series adds the necessary logic to arm64, allowing the (potentially unreliable) time stamping of early kernel messages. Tested on a bunch of arm64 systems, both bare-metal and in VMs. Boot tested on a x86 guest. [1] https://lore.kernel.org/patchwork/patch/1015110/ Marc Zyngier (3): printk: Allow architecture-specific timestamping function sched/clock: Allow sched_clock to inherit timestamp_clock epoch arm64: Allow early time stamping arch/arm64/Kconfig | 3 +++ arch/arm64/kernel/setup.c | 44 +++++++++++++++++++++++++++++++++++++ include/linux/sched/clock.h | 13 +++++++++++ kernel/printk/printk.c | 4 ++-- kernel/time/sched_clock.c | 10 +++++++++ 5 files changed, 72 insertions(+), 2 deletions(-) -- 2.20.1 Tested-by: Hanjun Guo