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=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 CBCC3C76188 for ; Mon, 22 Jul 2019 13:26:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A4F76218DA for ; Mon, 22 Jul 2019 13:26:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="t2NmYEvE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4F76218DA 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-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DJmQ2YrmzwQifFW4PRKIYTZIPFN2X4EDr7/wLzczqAw=; b=t2NmYEvEoPR51S ZovYvjU4ZtquRyN436+zfYJqIkLIP/LtvFrr/Y7BzKLua5KMDvQbJCj8Xzn4VHrnvA6Y9+LSQGaj2 Rt21urN1SMWg5tw2Q+Lw7MtHn1r1yON55jfSfvcHXlFhkqNex/dx58spRPvdl7EBZIdUg6Ku9l0cu keBtPgfttqR4WO7+0cMuTGu3aUKqyMdcrsskrEDrq4exH9ZBoLmonBICKYuc5qsC4wwUBpyvRkuKz tGn4RA9CwnXdCwGzfFxW/xFB2EVpcYkgF7cxDRX+hqDlksr5ef8vczCOZr2ib+/i7/nTR/Ag5ACZJ NKlDnffc0pQ3WQODf9fg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hpYKW-0002Nb-9V; Mon, 22 Jul 2019 13:26:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hpYKR-0002Ml-AQ for linux-arm-kernel@lists.infradead.org; Mon, 22 Jul 2019 13:26:14 +0000 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 C7F63344; Mon, 22 Jul 2019 06:26:10 -0700 (PDT) Received: from [10.1.197.61] (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 36EC83F71A; Mon, 22 Jul 2019 06:26:09 -0700 (PDT) Subject: Re: [PATCH 1/3] printk: Allow architecture-specific timestamping function To: Russell King - ARM Linux admin References: <20190722103330.255312-1-marc.zyngier@arm.com> <20190722103330.255312-2-marc.zyngier@arm.com> <20190722112543.5quvqgerpyvfgbxq@pathway.suse.cz> <493e2c0b-9536-ce6d-b59e-d169693085da@arm.com> <20190722130311.GD1330@shell.armlinux.org.uk> From: Marc Zyngier Openpgp: preference=signencrypt Autocrypt: addr=marc.zyngier@arm.com; prefer-encrypt=mutual; keydata= mQINBE6Jf0UBEADLCxpix34Ch3kQKA9SNlVQroj9aHAEzzl0+V8jrvT9a9GkK+FjBOIQz4KE g+3p+lqgJH4NfwPm9H5I5e3wa+Scz9wAqWLTT772Rqb6hf6kx0kKd0P2jGv79qXSmwru28vJ t9NNsmIhEYwS5eTfCbsZZDCnR31J6qxozsDHpCGLHlYym/VbC199Uq/pN5gH+5JHZyhyZiNW ozUCjMqC4eNW42nYVKZQfbj/k4W9xFfudFaFEhAf/Vb1r6F05eBP1uopuzNkAN7vqS8XcgQH qXI357YC4ToCbmqLue4HK9+2mtf7MTdHZYGZ939OfTlOGuxFW+bhtPQzsHiW7eNe0ew0+LaL 3wdNzT5abPBscqXWVGsZWCAzBmrZato+Pd2bSCDPLInZV0j+rjt7MWiSxEAEowue3IcZA++7 ifTDIscQdpeKT8hcL+9eHLgoSDH62SlubO/y8bB1hV8JjLW/jQpLnae0oz25h39ij4ijcp8N t5slf5DNRi1NLz5+iaaLg4gaM3ywVK2VEKdBTg+JTg3dfrb3DH7ctTQquyKun9IVY8AsxMc6 lxl4HxrpLX7HgF10685GG5fFla7R1RUnW5svgQhz6YVU33yJjk5lIIrrxKI/wLlhn066mtu1 DoD9TEAjwOmpa6ofV6rHeBPehUwMZEsLqlKfLsl0PpsJwov8TQARAQABtCNNYXJjIFp5bmdp ZXIgPG1hcmMuenluZ2llckBhcm0uY29tPokCTwQTAQIAOQIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQSf1RxT4LVjGP2VnD0j0NC60T16QwUCXR3BUgAKCRAj0NC60T16Qyd/D/9s x0puxd3lI+jdLMEY8sTsNxw/+CZfyKaHtysasZlloLK7ftYhRUc63mMW2mrvgB1GEnXYIdj3 g6Qo4csoDuN+9EBmejh7SglM/h0evOtrY2V5QmZA/e/Pqfj0P3N/Eb5BiB3R4ptLtvKCTsqr 3womxCRqQY3IrMn1s2qfpmeNLUIfCUtgh8opzPtFuFJWVBzbzvhPEApZzMe9Vs1O2P8BQaay QXpbzHaKruthoLICRzS/3UCe0N/mBZQRKHrqhPwvjZdO0KMqjSsPqfukOJ8bl5jZxYk+G/3T 66Z4JUpZ7RkcrX7CvBfZqRo19WyWFfjGz79iVMJNIEkJvJBANbTSiWUC6IkP+zT/zWYzZPXx XRlrKWSBBqJrWQKZBwKOLsL62oQG7ARvpCG9rZ6hd5CLQtPI9dasgTwOIA1OW2mWzi20jDjD cGC9ifJiyWL8L/bgwyL3F/G0R1gxAfnRUknyzqfpLy5cSgwKCYrXOrRqgHoB+12HA/XQUG+k vKW8bbdVk5XZPc5ghdFIlza/pb1946SrIg1AsjaEMZqunh0G7oQhOWHKOd6fH0qg8NssMqQl jLfFiOlgEV2mnaz6XXQe/viXPwa4NCmdXqxeBDpJmrNMtbEbq+QUbgcwwle4Xx2/07ICkyZH +7RvbmZ/dM9cpzMAU53sLxSIVQT5lj23WLkCDQROiX9FARAAz/al0tgJaZ/eu0iI/xaPk3DK NIvr9SsKFe2hf3CVjxriHcRfoTfriycglUwtvKvhvB2Y8pQuWfLtP9Hx3H+YI5a78PO2tU1C JdY5Momd3/aJBuUFP5blbx6n+dLDepQhyQrAp2mVC3NIp4T48n4YxL4Og0MORytWNSeygISv Rordw7qDmEsa7wgFsLUIlhKmmV5VVv+wAOdYXdJ9S8n+XgrxSTgHj5f3QqkDtT0yG8NMLLmY kZpOwWoMumeqn/KppPY/uTIwbYTD56q1UirDDB5kDRL626qm63nF00ByyPY+6BXH22XD8smj f2eHw2szECG/lpD4knYjxROIctdC+gLRhz+Nlf8lEHmvjHgiErfgy/lOIf+AV9lvDF3bztjW M5oP2WGeR7VJfkxcXt4JPdyDIH6GBK7jbD7bFiXf6vMiFCrFeFo/bfa39veKUk7TRlnX13go gIZxqR6IvpkG0PxOu2RGJ7Aje/SjytQFa2NwNGCDe1bH89wm9mfDW3BuZF1o2+y+eVqkPZj0 mzfChEsiNIAY6KPDMVdInILYdTUAC5H26jj9CR4itBUcjE/tMll0n2wYRZ14Y/PM+UosfAhf YfN9t2096M9JebksnTbqp20keDMEBvc3KBkboEfoQLU08NDo7ncReitdLW2xICCnlkNIUQGS WlFVPcTQ2sMAEQEAAYkCHwQYAQIACQUCTol/RQIbDAAKCRAj0NC60T16QwsFD/9T4y30O0Wn MwIgcU8T2c2WwKbvmPbaU2LDqZebHdxQDemX65EZCv/NALmKdA22MVSbAaQeqsDD5KYbmCyC czilJ1i+tpZoJY5kJALHWWloI6Uyi2s1zAwlMktAZzgGMnI55Ifn0dAOK0p8oy7/KNGHNPwJ eHKzpHSRgysQ3S1t7VwU4mTFJtXQaBFMMXg8rItP5GdygrFB7yUbG6TnrXhpGkFBrQs9p+SK vCqRS3Gw+dquQ9QR+QGWciEBHwuSad5gu7QC9taN8kJQfup+nJL8VGtAKgGr1AgRx/a/V/QA ikDbt/0oIS/kxlIdcYJ01xuMrDXf1jFhmGZdocUoNJkgLb1iFAl5daV8MQOrqciG+6tnLeZK HY4xCBoigV7E8KwEE5yUfxBS0yRreNb+pjKtX6pSr1Z/dIo+td/sHfEHffaMUIRNvJlBeqaj BX7ZveskVFafmErkH7HC+7ErIaqoM4aOh/Z0qXbMEjFsWA5yVXvCoJWSHFImL9Bo6PbMGpI0 9eBrkNa1fd6RGcktrX6KNfGZ2POECmKGLTyDC8/kb180YpDJERN48S0QBa3Rvt06ozNgFgZF Wvu5Li5PpY/t/M7AAkLiVTtlhZnJWyEJrQi9O2nXTzlG1PeqGH2ahuRxn7txA5j5PHZEZdL1 Z46HaNmN2hZS/oJ69c1DI5Rcww== Organization: ARM Ltd Message-ID: Date: Mon, 22 Jul 2019 14:26:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190722130311.GD1330@shell.armlinux.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190722_062611_451433_F77ECD73 X-CRM114-Status: GOOD ( 22.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Petr Mladek , Pavel Tatashin , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, Steven Rostedt , Sergey Senozhatsky , John Stultz , Thomas Gleixner , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 22/07/2019 14:03, Russell King - ARM Linux admin wrote: > On Mon, Jul 22, 2019 at 01:47:57PM +0100, Marc Zyngier wrote: >> On 22/07/2019 12:25, Petr Mladek wrote: >>> On Mon 2019-07-22 11:33:28, Marc Zyngier wrote: >>>> printk currently relies on local_clock to time-stamp the kernel >>>> messages. In order to allow the timestamping (and only that) >>>> to be overridden by architecture-specific code, let's declare >>>> a new timestamp_clock() function, which gets used by the printk >>>> code. Architectures willing to make use of this facility will >>>> have to define CONFIG_ARCH_HAS_TIMESTAMP_CLOCK. >>>> >>>> The default is of course to return local_clock(), so that the >>>> existing behaviour stays unchanged. >>>> >>>> Signed-off-by: Marc Zyngier >>>> --- >>>> include/linux/sched/clock.h | 13 +++++++++++++ >>>> kernel/printk/printk.c | 4 ++-- >>>> 2 files changed, 15 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/include/linux/sched/clock.h b/include/linux/sched/clock.h >>>> index 867d588314e0..3cf4b2a8ce18 100644 >>>> --- a/include/linux/sched/clock.h >>>> +++ b/include/linux/sched/clock.h >>>> @@ -98,4 +98,17 @@ static inline void enable_sched_clock_irqtime(void) {} >>>> static inline void disable_sched_clock_irqtime(void) {} >>>> #endif >>>> >>>> +#ifdef CONFIG_ARCH_HAS_TIMESTAMP_CLOCK >>>> +/* Special need architectures can provide their timestamping function */ >>> >>> The commit message and the above comment should be more specific >>> about what are the special needs. >>> >>> It must be clear how and why the clock differs from the other >>> clocks, especially from lock_clock(). >> >> Fair enough. How about something along the lines of: >> >> "An architecture can override the timestamp clock (which defaults to >> local_clock) if local_clock is not significant early enough (sched_clock >> being available too late)." > > We have: > 1) the standard clocksource > 2) the sched_clock, which is _supposed_ to be initialised early > 3) persistent_clock > > Do we really need another clock? > > Why not initialise sched_clock() early (as in, before sched_init(), > which is where the first sched_clock() read occurs) ? Because, as you hint at below, that's not generally possible if you need to identify the system early enough to discover that you need to apply an erratum workaround. If you init sched_clock() before you know what you're running on, you may end-up with a clock that can jump in either direction. And while the first call to sched_clock happens pretty late, the timestamping code uses it pretty early, via the local_clock() indirection. > > We've already been around the argument that sched_clock() apparently > can't be initialised early enough (which is the argument I had in reply > to the sched_clock() situation on ARM32) then how does inventing > timestamp_clock() solve this problem? It allows the kernel message to be timestamped with a potentially unreliable clock without breaking the promise that sched_clock() will not go backward or otherwise behave erratically. > Wouldn't timestamp_clock() also suffer from the very same "we can't > initialise it early enough" issue, and it'll just be setup along side > clocksources, just like sched_clock() has become? At least on arm64, the architected counter is always available, and doesn't require any setup (at least none by the time the kernel is booted). > I fail to see what adding yet another architecture specific clock > implementation buys, apart from yet more complexity. > It buys us early timestamping without forcing us to deal with an unreliable. The additional complexity looks pretty minimal to me, and no other architecture is forced to use it. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel