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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 53E30C43441 for ; Thu, 22 Nov 2018 14:14:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1A5E2206B2 for ; Thu, 22 Nov 2018 14:14:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A5E2206B2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388949AbeKWAyT (ORCPT ); Thu, 22 Nov 2018 19:54:19 -0500 Received: from foss.arm.com ([217.140.101.70]:50090 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732939AbeKWAyT (ORCPT ); Thu, 22 Nov 2018 19:54:19 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1216536B4; Thu, 22 Nov 2018 06:14:46 -0800 (PST) Received: from big-swifty.misterjones.org (big-swifty.cambridge.arm.com [10.1.39.198]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1B59E3F5AF; Thu, 22 Nov 2018 06:14:36 -0800 (PST) Date: Thu, 22 Nov 2018 14:14:29 +0000 Message-ID: <86lg5lrygq.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Pavel Tatashin Cc: Will Deacon , catalin.marinas@arm.com, akpm@linux-foundation.org, rppt@linux.vnet.ibm.com, mhocko@suse.com, ard.biesheuvel@linaro.org, andrew.murray@arm.com, james.morse@arm.com, sboyd@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/1] arm64: Early boot time stamps In-Reply-To: <20181121175841.if3vyumzvw3yoovi@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net> References: <20181120144340.30201-1-pasha.tatashin@soleen.com> <20181120144340.30201-2-pasha.tatashin@soleen.com> <20181121174706.GC9801@arm.com> <20181121175841.if3vyumzvw3yoovi@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Nov 2018 17:58:41 +0000, Pavel Tatashin wrote: > > On 18-11-21 17:47:07, Will Deacon wrote: > > > + /* > > > + * The arm64 boot protocol mandates that CNTFRQ_EL0 reflects > > > + * the timer frequency. To avoid breakage on misconfigured > > > + * systems, do not register the early sched_clock if the > > > + * programmed value if zero. Other random values will just > > > + * result in random output. > > > + */ > > > + if (!freq) > > > + return; > > > + > > > + arch_timer_read_counter = arch_counter_get_cntvct; > > > > Why do you need to assign this here? > > > > > + sched_clock_register(arch_timer_read_counter, ARCH_TIMER_NBITS, freq); > > > > arch_timer_read_counter can be reassigned once the arm_arch_timer driver > > has probed; what stops this from being unused as the sched_clock after that > > has happened? I worry that toggling the function pointer could lead to > > sched_clock() going backwards. > > No reason, I will revert it back to use a local variable. I think the issue is that you are doing an assignment for something that the kernel has already statically initialized. > I agree, time can go backward for a period of time while we switch > to permanent clock later, if that clock is different. It is worse than that. You're setting up sched_clock with an unreliable clock source which can go backward at any point, not just at handover time. I'd rather we have the timestamping code be able to use another souce than sched_clock, and eventually switch to it once sched_clock is registered (and properly corrected. Thanks, M. -- Jazz is not dead, it just smell funny.