From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 404AD261B8A for ; Fri, 17 Apr 2026 10:37:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776422265; cv=none; b=AjdXQnv273Chb7tUUr9+dR7WQJti6d0i6cMl8tNti8+Z5AchLQPFfaYdniJK280xXvZzvUn5rOi9AaQiiXMpA9F1JI1V83FrwLMlrknsHFW3ieHlPk3fcRnusJzZKRoJzXeTnYFB1ebxt+MSeJagpAAk57pqK1+NCANPBAEcO9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776422265; c=relaxed/simple; bh=MYdqFtDGO5Jur2DlfhQGrNDGBfzJhmaMJBUU7ueGzfA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YfFO6NBsAKsfW91xgIjuLJVxk5HpCiOqJcIRZdDqMh8ye5IqtrJhHfZbDchDRsuRqdSh1fiFX+5joFQMI39ry4+e4pf8e93yHDnlHY+vtqoPuiMT0aw13fCkolINASYk/nrwMt76CU0wn9kZO0eGsu7NPZA98SHy9Zg1DudH+Ws= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=ETaWY19g; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="ETaWY19g" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-488af96f6b2so7273535e9.0 for ; Fri, 17 Apr 2026 03:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1776422258; x=1777027058; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tv1i7Gd48Cnod7F4GCr1hVp16bcU9WsjF0Z3Mbm/gt4=; b=ETaWY19gkmjwa747KYIZogx+KjlnsrZmX1XOWAJH/X0r9wylVgTU+Jooy9MKJtCeQi hb0p8UFHC0AqxlSTERYuonfoEV62n0rMjO1XWAa7x2OjKr6u+sjiVDnPLj+bouY3YNXt NH9i6K216ouCbT7hQT8diCPywdg103mwLbpPScUR3cWk+gY6tZYXi6WqtXR8ZzkaLYvQ o8fgP9xyztjG1Qw3XTnZUegW3f0na1b5BWSd5dnPqUPAzYj36i1nbEF9FfsBLbChOQqd 8ZOXQOAgmuxIxTk/0vz6V2AOTWlyR6Qt1yfYtRDkR/V/f3RWvqlHKWQdB+ZLZ6DReGn7 QTiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776422258; x=1777027058; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tv1i7Gd48Cnod7F4GCr1hVp16bcU9WsjF0Z3Mbm/gt4=; b=p5MfFqKJfwIhNpA5GZByXsXyr+gdSXF8/38tPWqCOmwHe+jeuiWg6m0okeuh6xj1bP Zb/s6ZwtY2vN+zoYcKsy1UTBN5/Khvww+Dj7aGdCwTm4i8hutlorarhV+UXkaRGzJRvZ J1KdHnoq08f6pPe4xWc5q/QlxC7rwcoYhEs8tr784k3urSFHs+6Lm0muTvIrmEcLT0Wa LiFux30r/X6SO4rPr0AQolgMqWV8IHA97bABjuBGAfc+gN4+ybbp4ZvF6+xUX0I30Nmh hO+6eaMjhe/lF08E4uZExYAOYIr4wh6NU/hc8rtBMcQILTW75kRjVbENumHVtChRf/vX OtdA== X-Forwarded-Encrypted: i=1; AFNElJ+5PACYNcgQwpFchLx8Y52tEK7mmiWcyUl9h3Q0YUEkeEU1++kKEpAZqePiEDl8rRq+HJixydagLOjaBOE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzrxlg8YnHHQJHzQGSq+PPW7KUCzPn+Q3JIdhQ+gZNL8ncUPFUX HeOcmvSRD0yCl0rqwu6Rar6jyV0bGYFYPyDrBDybKQbKqc966bGJFrDqDCoYD9xIzFk= X-Gm-Gg: AeBDiet2F5cnqX263tZrUP7J1tJGNzgGJy8tBkrcACMif/99k0HFKMkexXas3zmROo5 QhlW5T32CJBI7PLmpFLxnRMn496t9WsZ6p3PsXn0yF+KV5vPGc0CxiP43lzU+e9uK57qpV+Yokr z5BxDqPX6SC4GmP2MiQAdy3FXteZEY3rfAUTY6Wn2eN3MTFOvN9T8tD/tzCobv0fAyfLYwwGz7i GLyXEt9mBcBFEVEYwNJqbl50eI01V+yTOUHrPl+qkWdp5kuD4ZigzS7BXnjqho88HmppWWDauEY ViY1E4wtZuk5nkjX+PsbdtHZ95eBtBYfVLp5dktIxZymkqn5ZwznR3+x3Y2jeE3LOEHbPdZ2YRm XAHn9tjRThew8pFxFdp41ODOVCXEaaykSgkyIf1XRBs35H+IMHTNgoquZBTGkbRfJfpiXGhttpC hPvo25iH2DWwk3g1/GxbpiWeJpdEibYwZEAwpr X-Received: by 2002:a05:600c:3546:b0:488:81b1:ae36 with SMTP id 5b1f17b1804b1-488fb7880camr31472095e9.23.1776422258295; Fri, 17 Apr 2026 03:37:38 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fb735d3dsm29077305e9.2.2026.04.17.03.37.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2026 03:37:37 -0700 (PDT) Date: Fri, 17 Apr 2026 12:37:35 +0200 From: Petr Mladek To: Thomas Gleixner Cc: Tim Bird , rostedt@goodmis.org, john.ogness@linutronix.de, senozhatsky@chromium.org, francesco@valla.it, geert@linux-m68k.org, shashankbalaji02@gmail.com, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Brian Masney Subject: Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot Message-ID: References: <20260410203741.997410-1-tim.bird@sony.com> <20260410203741.997410-2-tim.bird@sony.com> <87qzohdv6i.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87qzohdv6i.ffs@tglx> Adding Brian into Cc. On Wed 2026-04-15 00:38:29, Thomas Gleixner wrote: > On Fri, Apr 10 2026 at 14:37, Tim Bird wrote: > > + > > +#include > > +#ifdef CONFIG_ARM64 > > +#include > > +#endif > > + > > +#ifdef CONFIG_EARLY_CYCLES_KHZ > > +static inline u64 early_unsafe_cycles(void) > > +{ > > +#if defined(CONFIG_X86_64) > > + /* > > + * This rdtsc may happen before secure TSC is initialized, and > > + * it is unordered. So please don't use this value for cryptography > > + * or after SMP is initialized. > > + */ > > + return rdtsc(); > > +#elif defined(CONFIG_ARM64) > > + return read_sysreg(cntvct_el0); > > +#elif defined(CONFIG_RISCV_TIMER) > > + u64 val; > > + > > + asm volatile("rdtime %0" : "=r"(val)); > > + return val; > > +#else > > + return 0; > > +#endif > > +} > > No. Generic code and generic headers have no business to implement any > architecture specific code and there is zero justification for > architecture specific #ifdefs in generic code. Yeah, this looks a bit wild. > > +/* returns a nanosecond value based on early cycles */ > > +static inline u64 early_times_ns(void) > > +{ > > + if (CONFIG_EARLY_CYCLES_KHZ) > > + /* > > + * Note: the multiply must precede the division to avoid > > + * truncation and loss of resolution > > + * Don't use fancier MULT/SHIFT math here. Since this is > > + * static, the compiler can optimize the math operations. > > + */ > > + return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ; > > This code will result in a division by zero warning from any reasonable > compiler because this is evaluated _before_ it is eliminated. > > > @@ -2294,6 +2295,8 @@ int vprintk_store(int facility, int level, > > * timestamp with respect to the caller. > > */ > > ts_nsec = local_clock(); > > + if (unlikely(!ts_nsec)) > > + ts_nsec = early_times_ns(); > > I explained to you how this wants to be implemented to be useful and you > declared that you are unwilling to put the effort in. > > My NAK for this disgusting and tasteless hack still applies. > > Either you are willing to work with the community and the relevant > maintainers or you can keep your hackery maintained out of tree for > those who care about it and are willing to ignore the fallout. The discussion went wild and is full of emotions. Let me summarize my understanding: There are people who try to optimize boot times. Tim is one of them. He used an out-of-tree patch for many years. He decided to share it to make the life easier for others. Tim's original approach was trivial [Tim1]. IMHO, he used a cycle counter with a stable frequency and hardcoded the computation to timestamps. It opened discussion how to integrate it better: 1. Avoid hard coded value in Kconfig by some calibration [Tim2][Tim3] One hardcoded value is back in [Tim4] for simplicity. 2. Avoid jump in the timestamps when timekeeping is allowed. It was partly removed in [v2][v3] by already "calibrated" timestamps read by userspace (syslog, /dev/kmsg). Again, this approach was removed in v4 for simplicity. Pros of v4: + very simple + gives some reasonably looking timestamps + might be good enough for the purpose Cons of v4: + hacky, does not compile in some case, ... + hardcoded value in config + jump in timestamps when timekeeping is initialized Now, we have alternative approach by Thomas [Thomas1] which allows to initialize time keeping on x86 ASAP: Pros: + clean and well integrated with timekeeping + no hard coded values in Kconfig + no jump in timestamps Cons: + need non-trivial changes for each supported architecture + no timestamps for the very early code (30ms on the measured x86_64) My view: Thomas' approach is great because it is clean integration, ... but: 1. I am not sure if the complexity is worth it. There are only few people (Tim's tip is 50) who are interested into the early boot times and all are developers. 2. It does not cover the very early boot. And Brian mentioned a real life problem found in this area, see https://lore.kernel.org/all/acxx9Bt0N3nhtLgN@redhat.com/ Steven mentioned getting the very early timestamps from the firmware, see https://lore.kernel.org/all/20260401111244.5057a89c@gandalf.local.home/ But I am not sure how complicated it is. And if it does not need any special HW or so. Tim's approach is interesting because of the simplicity and might be good enough for the few (50) users. I think that there are basically two problems with Tim's approach: 1. It needs a reasonable API to get a cycle counter with a stable frequency. My understanding is that get_cycles() might be good enough. The only problem is that it the stability is not guaranteed and it is not calibrated. Would it help to rename it to get_bogo_cycles() ? 2. The early timestamps provided by the bogo cycles are not synchronized with timestamps from the proper time keeping. Would it help to print a disclaimer, similar to, for example, trace_printk() first use? Something like: [ 0.002912] ********************************************************** [ 0.002917] **** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE [ 0.002921] ** [ 0.002935] ** Using BOGO early timestamps [ 0.002939] ** [ 0.002943] ** They are not properly calibrated and might use a source [ 0.002949] ** with an unstable frequency. [ 0.002953] ** [ 0.002957] ** They are not comparable with timestamps after [ 0.002961] ** the timekeeping is initialized. [ 0.002966] ** [ 0.002968] **** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE [ 0.002971] ******************************************************* [ 0.002975] Booting Linux on physical CPU 0x0000000000 [0x410fd083] [ 0.002998] Linux version 7.0.0-rc6-v8+ (tbird@timdesk) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #20 SMP PREEMPT Fri Apr 10 11:57:48 MDT 2026 [ 0.003002] KASLR enabled [ 0.003338] random: crng init done [ 0.003866] Machine model: Raspberry Pi 4 Model B Rev 1.5 [ 0.004495] efi: UEFI not found. ... [ 0.183552] Root IRQ handler: gic_handle_irq [ 0.183561] GIC: Using split EOI/Deactivate mode [ 0.183699] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 0.183958] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns [ 0.183952] arch_timer: cp15 timer running at 54.00MHz (phys). [ 0.183957] ********************************************************** [ 0.183962] **** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE [ 0.183967] ** [ 0.183971] ** End of BOGO early timestamps [ 0.183976] ** [ 0.183982] **** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE [ 0.183989] ********************************************************** [ 0.000000] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns [ 0.000157] Console: colour dummy device 80x25 [ 0.000165] printk: legacy console [tty1] enabled My view is that it would be nice to make the life easier for the 50 developers who do very useful work. But we do not need to create and maintain any complicated code for this. If the bogo cycles are good enough. If they already have some users and have to stay anyway. If we make it clear that the early timestamps are bogus... IMHO, the main risk is that it won't be used just by the 50 developers but it will get misused and open some can of worms. I think that the risk might be acceptable but... What do you think, please? Am I too naive in this case? [Tim1] https://lore.kernel.org/all/39b09edb-8998-4ebd-a564-7d594434a981@bird.org/ [Tim2] https://lore.kernel.org/all/20260124194027.713991-1-tim.bird@sony.com/ [Tim3] https://lore.kernel.org/all/20260210234741.3262320-1-tim.bird@sony.com/ [Tim4] https://lore.kernel.org/all/20260410203741.997410-1-tim.bird@sony.com/ [Thomas1] https://lore.kernel.org/all/87fr5ib6ks.ffs@tglx/ Best Regards, Petr