[PATCH v4 0/1] printk: fix zero-valued printk timestamps

[PATCH v4 0/1] printk: fix zero-valued printk timestamps

[Tim Bird]

Some kernel messages emitted before kernel timekeeping is started
have a timestamp value of zero.  However, some platforms
have a cycle counter or timer register that is initialized
before the kernel starts (either in hardware or pre-kernel
firmware), and it can be accessed to provide uncalibrated
values before any other kernel initialization.  I refer
to this period where kernel timestamps are zero as the
printk timing "blind spot".

The following patch allows developers to set a config value
CONFIG_EARLY_CYCLES_KHZ, that will be used to provide
useful timestamps on early printk messages.
This calibration value is set as a static configuration
variable, since it must be available from the very first kernel
instruction.  Since this value is machine-specific, it cannot
be used in the .config for a generic distribution kernel.
The feature is presented here as something useful for
kernel developers working on boot-time optimization
(ie, as something that can be used temporarily during boot
time research and development work, and not necessarily
a runtime option for the average user).

Different platforms have different blind spot durations.
On an x86_64 platform, due to early tsc initialization, the
blind spot may be as small at 16 milliseconds.  On a
Raspberry Pi 4 board, it is approximately 180 milliseconds.
On a RISC V BeagleV Fire board, it can be up to 1700
milliseconds (1.7 seconds).  On some platforms, the blind spot
duration is a significant percentage of the time before user-space
initialization in the kernel (greater than 20%).

This feature uses a different mechanism to gather timestamp values.
When kernel timekeeping starts, the printk timestamps change
to a new timebase based on local_clock(), and timestamp values
reset to the baseline used for kernel timekeeping. This results in a
one-time discontinuity in timestamps between early printks and later
printks. The discontinuity should be obvious to humans, but could
possibly confuse tools.

Here is before and after dmesg output for a Raspberry PI 4 board:

before:
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
[    0.000000] Linux version 7.0.0-rc3-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) #5 SMP PREEMPT Wed Mar 11 18:30:18 MDT 2026
[    0.000000] KASLR enabled
[    0.000000] random: crng init done
[    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.5
[    0.000000] efi: UEFI not found.
...
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] arch_timer: cp15 timer running at 54.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[    0.000000] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[    0.000161] Console: colour dummy device 80x25
[    0.000170] printk: legacy console [tty1] enabled

after:
[    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.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


Tim Bird (1):
  printk: fix zero-valued printk timestamps in early boot

 include/linux/early_times.h | 55 +++++++++++++++++++++++++++++++++++++
 init/Kconfig                | 30 ++++++++++++++++++++
 kernel/printk/printk.c      |  3 ++
 3 files changed, 88 insertions(+)
 create mode 100644 include/linux/early_times.h

-- 
2.43.0

[PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Tim Bird]

During early boot, printk timestamps are reported as zero before
kernel timekeeping starts (i.e. before time_init()).  This
hinders boot-time optimization efforts.  This period ranges from
17 to 1700 milliseconds on different embedded machines running Linux.

Add support for early timestamps based on processor cycle-generators
that need no kernel initialization. Use a statically-configured
frequency value for converting cycles to nanoseconds. This means
that this feature cannot be turned on in generic distro kernels.
It is intended for temporary use during kernel development and
boot-time research and optimization only.

This yields non-zero timestamps for printks from the very start
of kernel execution.  The timestamps are relative to the start of
an architecture-specific counter (e.g. tsc on x86_64 and cntvct_el0
on arm64).  Affected timestamps reflect time from cycle counter
init (usually machine power-on or virtual machine start) instead of
time from the kernel's timekeeping initialization. This results in a
discontinuity in the printk timestamp values, one time, when
kernel timekeeping starts.

Signed-off-by: Tim Bird <tim.bird@sony.com>
---
V3 -> V4
  Replace config vars with single one: CONFIG_EARLY_CYCLES_KHZ
  Replace runtime calibration with static config variable
  Remove reference to get_cycles()
  Add support for RISCV platforms
V2 -> V3
  Default CONFIG option to 'n'
  Move more code into early_times.h (reduce ifdefs in init/main.c)
  Use match64 helper routines
  Use cycles_t instead of u64 type
  Add #defines for EARLY_CYCLES_BIT and EARLY_CYCLES_MASK
  Invert if logic in adjust_early_ts()
V1 -> V2
  Remove calibration CONFIG vars
  Add 'depends on' to restrict arches (to handle ppc bug)
  Add early_ts_offset to avoid discontinuity
  Save cycles in ts_nsec, and convert on output
  Move conditional code to include file (early_times.h>
---
 include/linux/early_times.h | 55 +++++++++++++++++++++++++++++++++++++
 init/Kconfig                | 30 ++++++++++++++++++++
 kernel/printk/printk.c      |  3 ++
 3 files changed, 88 insertions(+)
 create mode 100644 include/linux/early_times.h

diff --git a/include/linux/early_times.h b/include/linux/early_times.h
new file mode 100644
index 000000000000..82bacfd0e26b
--- /dev/null
+++ b/include/linux/early_times.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _EARLY_TIMES_H
+#define _EARLY_TIMES_H
+
+#include <linux/timekeeping.h>
+#ifdef CONFIG_ARM64
+#include <asm/sysreg.h>
+#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
+}
+
+#define NS_PER_KHZ	1000000UL
+
+/* 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;
+	return 0;
+}
+#else
+static inline u64 early_times_ns(void)
+{
+	return 0;
+}
+#endif
+
+#endif /* _EARLY_TIMES_H */
diff --git a/init/Kconfig b/init/Kconfig
index 7484cd703bc1..40c3123c2c27 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -792,6 +792,36 @@ config IKHEADERS
 	  or similar programs.  If you build the headers as a module, a module called
 	  kheaders.ko is built which can be loaded on-demand to get access to headers.
 
+config EARLY_CYCLES_KHZ
+	int "Frequency of the early times cycle counter, in KHz"
+	default 0
+	depends on PRINTK
+	depends on ARM64 || X86_64 || RISCV_TIMER
+	help
+	  Specifies the frequency value (in KHz) of the cycle counter
+	  used for early times information.
+
+	  Set this to provide timing information for printks in early boot
+	  (before the start of kernel timekeeping), that would otherwise
+	  show as 0.
+
+	  To calculate the value for your system, boot your system, and
+	  use the value expressed on the tsc or cntvct_el0 calibration line
+	  in your kernel message log:
+	  ex x86_64: tsc: Refined TSC clocksource calibration: 2095.057 MHz
+          In that case, use the value 2095057.
+	  ex arm64: arch_timer: cp15 timer running at 54.00MHz (phys).
+	  In that case, use the value of 54000.
+
+	  Note that this causes the kernel to show, for some early printks,
+	  times that are relative to processor power on, instead of
+	  relative to the start of kernel timekeeping.  When kernel
+	  timekeeping starts, the timestamps values reset, causing
+	  a discontinuity in the timestamp values.  If you see
+	  non-monotonic printk timestamps, please don't freak out.
+
+	  Set to 0 to disable this feature.
+
 config LOG_BUF_SHIFT
 	int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
 	range 12 25
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0323149548f6..ddeab81f04ef 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -46,6 +46,7 @@
 #include <linux/ctype.h>
 #include <linux/uio.h>
 #include <linux/sched/clock.h>
+#include <linux/early_times.h>
 #include <linux/sched/debug.h>
 #include <linux/sched/task_stack.h>
 #include <linux/panic.h>
@@ -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();
 
 	caller_id = printk_caller_id();
 
-- 
2.43.0

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[kernel test robot]

Hi Tim,

kernel test robot noticed the following build warnings:

[auto build test WARNING on linus/master]
[also build test WARNING on v7.0-rc7 next-20260410]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Tim-Bird/printk-fix-zero-valued-printk-timestamps-in-early-boot/20260412-134726
base:   linus/master
patch link:    https://lore.kernel.org/r/20260410203741.997410-2-tim.bird%40sony.com
patch subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20260412/202604121822.OvOLcTnO-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260412/202604121822.OvOLcTnO-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604121822.OvOLcTnO-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from kernel/printk/printk.c:49:
   include/linux/early_times.h: In function 'early_times_ns':
>> include/linux/early_times.h:45:61: warning: division by zero [-Wdiv-by-zero]
      45 |                 return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
         |                                                             ^


vim +45 include/linux/early_times.h

    34	
    35	/* returns a nanosecond value based on early cycles */
    36	static inline u64 early_times_ns(void)
    37	{
    38		if (CONFIG_EARLY_CYCLES_KHZ)
    39			/*
    40			 * Note: the multiply must precede the division to avoid
    41			 * truncation and loss of resolution
    42			 * Don't use fancier MULT/SHIFT math here.  Since this is
    43			 * static, the compiler can optimize the math operations.
    44			 */
  > 45			return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
    46		return 0;
    47	}
    48	#else
    49	static inline u64 early_times_ns(void)
    50	{
    51		return 0;
    52	}
    53	#endif
    54	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

RE: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Bird, Tim]

Hmmm,

This is a false positive warning from the compiler (see below).

I apologize for not catching it.   I did test with CONFIG_EARLY_CYCLES=0
and I'm not sure why I didn't see the warning.

I'll see if I can silence this warning.

> -----Original Message-----
> From: kernel test robot <lkp@intel.com>
> Sent: Sunday, April 12, 2026 4:11 AM
> Hi Tim,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on linus/master]
> [also build test WARNING on v7.0-rc7 next-20260410]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Tim-Bird/printk-fix-zero-valued-printk-timestamps-in-early-boot/20260412-134726
> base:   linus/master
> patch link:    https://lore.kernel.org/r/20260410203741.997410-2-tim.bird%40sony.com
> patch subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
> config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20260412/202604121822.OvOLcTnO-lkp@intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 15.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260412/202604121822.OvOLcTnO-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202604121822.OvOLcTnO-lkp@intel.com/
> 
> All warnings (new ones prefixed by >>):
> 
>    In file included from kernel/printk/printk.c:49:
>    include/linux/early_times.h: In function 'early_times_ns':
> >> include/linux/early_times.h:45:61: warning: division by zero [-Wdiv-by-zero]
>       45 |                 return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
>          |                                                             ^
> 
> 
> vim +45 include/linux/early_times.h
> 
>     34
>     35	/* returns a nanosecond value based on early cycles */
>     36	static inline u64 early_times_ns(void)
>     37	{
>     38		if (CONFIG_EARLY_CYCLES_KHZ)
>     39			/*
>     40			 * Note: the multiply must precede the division to avoid
>     41			 * truncation and loss of resolution
>     42			 * Don't use fancier MULT/SHIFT math here.  Since this is
>     43			 * static, the compiler can optimize the math operations.
>     44			 */
>   > 45			return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
Based on this conditional, it's not possible for CONFIG_EARLY_CYCLES_KHZ to be zero
on this line of code.  Does GCC not catch this?
if (0)
   x = <some expression>/0;

So this is a false positive.

>     46		return 0;
>     47	}
>     48	#else
>     49	static inline u64 early_times_ns(void)
>     50	{
>     51		return 0;
>     52	}
>     53	#endif
>     54
> 
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[David Laight]

On Mon, 13 Apr 2026 17:58:34 +0000
"Bird, Tim" <Tim.Bird@sony.com> wrote:

> Hmmm,
> 
> This is a false positive warning from the compiler (see below).
> 
> I apologize for not catching it.   I did test with CONFIG_EARLY_CYCLES=0
> and I'm not sure why I didn't see the warning.
> 
> I'll see if I can silence this warning.
> 
> > -----Original Message-----
> > From: kernel test robot <lkp@intel.com>
> > Sent: Sunday, April 12, 2026 4:11 AM
> > Hi Tim,
> > 
> > kernel test robot noticed the following build warnings:
> > 
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v7.0-rc7 next-20260410]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > 
> > url:    https://github.com/intel-lab-lkp/linux/commits/Tim-Bird/printk-fix-zero-valued-printk-timestamps-in-early-boot/20260412-134726
> > base:   linus/master
> > patch link:    https://lore.kernel.org/r/20260410203741.997410-2-tim.bird%40sony.com
> > patch subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
> > config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20260412/202604121822.OvOLcTnO-lkp@intel.com/config)
> > compiler: aarch64-linux-gcc (GCC) 15.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260412/202604121822.OvOLcTnO-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202604121822.OvOLcTnO-lkp@intel.com/
> > 
> > All warnings (new ones prefixed by >>):
> > 
> >    In file included from kernel/printk/printk.c:49:
> >    include/linux/early_times.h: In function 'early_times_ns':  
> > >> include/linux/early_times.h:45:61: warning: division by zero [-Wdiv-by-zero]  
> >       45 |                 return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
> >          |                                                             ^
> > 
> > 
> > vim +45 include/linux/early_times.h
> > 
> >     34
> >     35	/* returns a nanosecond value based on early cycles */
> >     36	static inline u64 early_times_ns(void)
> >     37	{
> >     38		if (CONFIG_EARLY_CYCLES_KHZ)
> >     39			/*
> >     40			 * Note: the multiply must precede the division to avoid
> >     41			 * truncation and loss of resolution
> >     42			 * Don't use fancier MULT/SHIFT math here.  Since this is
> >     43			 * static, the compiler can optimize the math operations.
> >     44			 */  
> >   > 45			return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;  
> Based on this conditional, it's not possible for CONFIG_EARLY_CYCLES_KHZ to be zero
> on this line of code.  Does GCC not catch this?
> if (0)
>    x = <some expression>/0;
> 
> So this is a false positive.

I suspect the warning is being generated before the optimiser throws
the code away as unreachable.
You might have to do:
	return (early_unsafe_cycles() * NS_PER_KHZ) / (CONFIG_EARLY_CYCLES_KHZ ?: 1);

David

> 
> >     46		return 0;
> >     47	}
> >     48	#else
> >     49	static inline u64 early_times_ns(void)
> >     50	{
> >     51		return 0;
> >     52	}
> >     53	#endif
> >     54
> > 
> > --
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki  

RE: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Thomas Gleixner]

On Mon, Apr 13 2026 at 17:58, Tim Bird wrote:
> This is a false positive warning from the compiler (see below).

This is _NOT_ a false positive warning. The compiler is absolutely
correct.

>>     34
>>     35	/* returns a nanosecond value based on early cycles */
>>     36	static inline u64 early_times_ns(void)
>>     37	{
>>     38		if (CONFIG_EARLY_CYCLES_KHZ)
>>     39			/*
>>     40			 * Note: the multiply must precede the division to avoid
>>     41			 * truncation and loss of resolution
>>     42			 * Don't use fancier MULT/SHIFT math here.  Since this is
>>     43			 * static, the compiler can optimize the math operations.
>>     44			 */
>>   > 45			return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
> Based on this conditional, it's not possible for CONFIG_EARLY_CYCLES_KHZ to be zero
> on this line of code.  Does GCC not catch this?
> if (0)
>    x = <some expression>/0;
>
> So this is a false positive.

You clearly fail to understand how compilers work. The dead code
elimination happens _after_ the evaluation of the code and the compiler
does not care whether your initial condition evaluated to false or
not. That's documented compiler behaviour,

Whether GCC complains about it or not is completely irrelevant.

> I'll see if I can silence this warning.

Don't put much effort into it. This whole hack is going nowhere.

Thanks,

        tglx

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[kernel test robot]

Hi Tim,

kernel test robot noticed the following build warnings:

[auto build test WARNING on linus/master]
[also build test WARNING on v7.0-rc7 next-20260410]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Tim-Bird/printk-fix-zero-valued-printk-timestamps-in-early-boot/20260412-134726
base:   linus/master
patch link:    https://lore.kernel.org/r/20260410203741.997410-2-tim.bird%40sony.com
patch subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
config: um-defconfig (https://download.01.org/0day-ci/archive/20260412/202604121907.nsngvl5u-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project ae825cb8cea7f3ac8e5e4096f22713845cf5e501)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260412/202604121907.nsngvl5u-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604121907.nsngvl5u-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from kernel/printk/printk.c:49:
   include/linux/early_times.h:20:9: error: call to undeclared function 'rdtsc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
      20 |         return rdtsc();
         |                ^
>> include/linux/early_times.h:45:47: warning: division by zero is undefined [-Wdivision-by-zero]
      45 |                 return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
         |                                                             ^ ~~~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.


vim +45 include/linux/early_times.h

    34	
    35	/* returns a nanosecond value based on early cycles */
    36	static inline u64 early_times_ns(void)
    37	{
    38		if (CONFIG_EARLY_CYCLES_KHZ)
    39			/*
    40			 * Note: the multiply must precede the division to avoid
    41			 * truncation and loss of resolution
    42			 * Don't use fancier MULT/SHIFT math here.  Since this is
    43			 * static, the compiler can optimize the math operations.
    44			 */
  > 45			return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
    46		return 0;
    47	}
    48	#else
    49	static inline u64 early_times_ns(void)
    50	{
    51		return 0;
    52	}
    53	#endif
    54	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[kernel test robot]

Hi Tim,

kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v7.0-rc7 next-20260410]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Tim-Bird/printk-fix-zero-valued-printk-timestamps-in-early-boot/20260412-134726
base:   linus/master
patch link:    https://lore.kernel.org/r/20260410203741.997410-2-tim.bird%40sony.com
patch subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
config: um-defconfig (https://download.01.org/0day-ci/archive/20260412/202604122037.R14cnXpl-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project ae825cb8cea7f3ac8e5e4096f22713845cf5e501)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260412/202604122037.R14cnXpl-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604122037.R14cnXpl-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from kernel/printk/printk.c:49:
>> include/linux/early_times.h:20:9: error: call to undeclared function 'rdtsc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
      20 |         return rdtsc();
         |                ^
   include/linux/early_times.h:45:47: warning: division by zero is undefined [-Wdivision-by-zero]
      45 |                 return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
         |                                                             ^ ~~~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.


vim +/rdtsc +20 include/linux/early_times.h

    10	
    11	#ifdef CONFIG_EARLY_CYCLES_KHZ
    12	static inline u64 early_unsafe_cycles(void)
    13	{
    14	#if defined(CONFIG_X86_64)
    15		/*
    16		 * This rdtsc may happen before secure TSC is initialized, and
    17		 * it is unordered. So please don't use this value for cryptography
    18		 * or after SMP is initialized.
    19		 */
  > 20		return rdtsc();
    21	#elif defined(CONFIG_ARM64)
    22		return read_sysreg(cntvct_el0);
    23	#elif defined(CONFIG_RISCV_TIMER)
    24		u64 val;
    25	
    26		asm volatile("rdtime %0" : "=r"(val));
    27		return val;
    28	#else
    29		return 0;
    30	#endif
    31	}
    32	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Geert Uytterhoeven]

Hi Tim,

Thanks for your patch!

On Fri, 10 Apr 2026 at 22:38, Tim Bird <tim.bird@sony.com> wrote:
> During early boot, printk timestamps are reported as zero before
> kernel timekeeping starts (i.e. before time_init()).  This
> hinders boot-time optimization efforts.  This period ranges from
> 17 to 1700 milliseconds on different embedded machines running Linux.
>
> Add support for early timestamps based on processor cycle-generators
> that need no kernel initialization. Use a statically-configured
> frequency value for converting cycles to nanoseconds. This means
> that this feature cannot be turned on in generic distro kernels.
> It is intended for temporary use during kernel development and
> boot-time research and optimization only.
>
> This yields non-zero timestamps for printks from the very start
> of kernel execution.  The timestamps are relative to the start of
> an architecture-specific counter (e.g. tsc on x86_64 and cntvct_el0
> on arm64).  Affected timestamps reflect time from cycle counter
> init (usually machine power-on or virtual machine start) instead of
> time from the kernel's timekeeping initialization. This results in a
> discontinuity in the printk timestamp values, one time, when
> kernel timekeeping starts.

Won't it be hard to see where the discontinuity happens in some cases?
Perhaps this can be made more obvious by not doing the time conversion
in kernelspace, like in your first version?

> Signed-off-by: Tim Bird <tim.bird@sony.com>

> --- /dev/null
> +++ b/include/linux/early_times.h

> +/* 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;

Still, this contains a 64-by-32 division, so let's see how this works
out on 32-bit (RISCV_TIMER is set on rv32!).  If the compiler would
generate a function call to a libgcc helper, you will have to switch
to the mul_u64_u32_div() helper...

> +       return 0;
> +}
> +#else
> +static inline u64 early_times_ns(void)
> +{
> +       return 0;
> +}
> +#endif
> +
> +#endif /* _EARLY_TIMES_H */

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Tue, 14 Apr 2026 at 09:03, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Tim,
>
> Thanks for your patch!
>
> On Fri, 10 Apr 2026 at 22:38, Tim Bird <tim.bird@sony.com> wrote:
> > During early boot, printk timestamps are reported as zero before
> > kernel timekeeping starts (i.e. before time_init()).  This
...
> Won't it be hard to see where the discontinuity happens in some cases?
> Perhaps this can be made more obvious by not doing the time conversion
> in kernelspace, like in your first version?
>
> > Signed-off-by: Tim Bird <tim.bird@sony.com>
>
> > --- /dev/null
> > +++ b/include/linux/early_times.h
>
> > +/* 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;
>
> Still, this contains a 64-by-32 division, so let's see how this works
> out on 32-bit (RISCV_TIMER is set on rv32!).  If the compiler would
> generate a function call to a libgcc helper, you will have to switch
> to the mul_u64_u32_div() helper...

Interesting.

https://github.com/robang74/uchaosys/blob/53e72d169/cnfg/printk-fix-early-boot-timestamps-patch-v4.txt#L92

Elvis the King (A?:), R-

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Thomas Gleixner]

On Fri, Apr 10 2026 at 14:37, Tim Bird wrote:
> +
> +#include <linux/timekeeping.h>
> +#ifdef CONFIG_ARM64
> +#include <asm/sysreg.h>
> +#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.

Ask your favourite AI assistant for an opinion.

> +#define NS_PER_KHZ	1000000UL

The existing nomenclature for nanosecond related constants is NSEC_* 

> +
> +/* 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. 

Thanks,

        tglx

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Wed, 15 Apr 2026 at 00:38, Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Fri, Apr 10 2026 at 14:37, Tim Bird wrote:
> > +
> > +#include <linux/timekeeping.h>
> > +#ifdef CONFIG_ARM64
> > +#include <asm/sysreg.h>
> > +#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.

This translates in practice in early_unsafe_cycles() various
instances, one for each architecture supported. Even better a macro
for each architecture like this example below (untested code, just for
exemplification):

  ts_nsec = local_clock();
#ifdef CONFIG_EARLY_CYCLES_KHZ
#if defined(CONFIG_ARM64)
#include <asm/sysreg.h>
#define early_unsafe_cycles read_sysreg(cntvct_el0);
#elif defined(CONFIG_X86_64)
#define early_unsafe_cycles rdtsc()
#elif defined(CONFIG_RISCV_TIMER)
#define early_unsafe_cycles ({ u64 val; asm volatile("rdtime %0" :
"=r"(val)); val; })
#else
#define early_unsafe_cycles 0
#endif
+ if (unlikely(!ts_nsec))
+ ts_nsec = early_times_ns();
 #endif // CONFIG_EARLY_CYCLES_KHZ
  caller_id = printk_caller_id();

While keeping architectures separate is for abstraction layer best
practice, in very specific cases abstraction can be a meaningless
concept or much less important than having a single file for a single
feature (the complementary way of organising stuff). Because in Linux
the abstraction layer approach applies for architectures, the gap
between aesthetic and a specific case like an early boot macros set
hack for debugging is to clarify the exception from the general rule
in the header itself.

On Wed, 15 Apr 2026 at 00:38, Thomas Gleixner <tglx@kernel.org> wrote: (to TIM)
>
> Ask your favourite AI assistant for an opinion.

(Roberto maintaining the cold blood in front of "Tim's overlooking a
false positive gcc warning" and check Thomas suggestion just for the
sake of curiosity)

Gemini Thinking AI: Whether or not you can justify this exception
depends entirely on whether this is a permanent feature or a transient
debug hack.

Cheers, R-

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

[-- Attachment #1: Type: text/plain, Size: 3680 bytes --]

On Wed, 15 Apr 2026 at 02:19, Roberto A. Foglietta
<roberto.foglietta@gmail.com> wrote:
>
> On Wed, 15 Apr 2026 at 00:38, Thomas Gleixner <tglx@kernel.org> wrote:
> >
> > On Fri, Apr 10 2026 at 14:37, Tim Bird wrote:
> > > +
> > > +#include <linux/timekeeping.h>
> > > +#ifdef CONFIG_ARM64
> > > +#include <asm/sysreg.h>
> > > +#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.
>
> This translates in practice in early_unsafe_cycles() various
> instances, one for each architecture supported. Even better a macro
> for each architecture like this example below (untested code, just for
> exemplification):
>
>   ts_nsec = local_clock();
> #ifdef CONFIG_EARLY_CYCLES_KHZ
> #if defined(CONFIG_ARM64)
> #include <asm/sysreg.h>
> #define early_unsafe_cycles read_sysreg(cntvct_el0);
> #elif defined(CONFIG_X86_64)
> #define early_unsafe_cycles rdtsc()
> #elif defined(CONFIG_RISCV_TIMER)
> #define early_unsafe_cycles ({ u64 val; asm volatile("rdtime %0" :
> "=r"(val)); val; })
> #else
> #define early_unsafe_cycles 0
> #endif
> + if (unlikely(!ts_nsec))
> + ts_nsec = early_times_ns();
>  #endif // CONFIG_EARLY_CYCLES_KHZ
>   caller_id = printk_caller_id();
>
> While keeping architectures separate is for abstraction layer best
> practice, in very specific cases abstraction can be a meaningless
> concept or much less important than having a single file for a single
> feature (the complementary way of organising stuff). Because in Linux
> the abstraction layer approach applies for architectures, the gap
> between aesthetic and a specific case like an early boot macros set
> hack for debugging is to clarify the exception from the general rule
> in the header itself.

IMHO, this patch (upstreamed or not) is for a few hackers and it is
not even a tool but a first-outlook or last-resort hack. Therefore the
single point of change that makes sense against spreading stuff that
is supposed to be further hacked isn't the correct approach. The
debate can be about upstreaming this kind of changes, and IMHO this
one still has a sense to be upstreamed among debug features.

I am attaching the path for just sake of independence storage (due my
project github repo linked before is naturally subject to arbitrary
changes by me). It is not supposed to be applied as-is (and probably
cannot be applied anyway) and the patch has been written by hands on a
keyboard. Gemini was used for retrieving information (in a smart man 3
command style) and to collect the ASM code and its fencing.

So the main question is: does this v5 suggested approach bridge the
1-single-point-of-change practical needs with the aim of keeping the
source three? If yes then a V6 is worth being developed to provide the
functionality and propose the upstream (I do not bet in good at the
first write but on resolving the contrast/debate THEN delivery).

Best regards, R-

[-- Attachment #2: printk-fix-early-boot-timestamps-patch-v4.txt --]
[-- Type: text/plain, Size: 5555 bytes --]

This is a heavily "refactored by hands" patch (example) based on the one by

From: Tim Bird <tim.bird@sony.com>
Subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
Date: Fri, 10 Apr 2026 14:37:41 -0600
Message-ID: <20260410203741.997410-2-tim.bird@sony.com>

During early boot, printk timestamps are reported as zero before
kernel timekeeping starts (i.e. before time_init()).  This
hinders boot-time optimization efforts.  This period ranges from
17 to 1700 milliseconds on different embedded machines running Linux.

Add support for early timestamps based on processor cycle-generators
that need no kernel initialization.This feature isn't intended for a 
generic distro kernels but for temporary use during kernel development
and boot-time research and optimization by kernel hackers only.

This yields non-zero timestamps for printks from the very start
of kernel execution.  The timestamps are relative to the start of
an architecture-specific counter (e.g. tsc on x86_64 and cntvct_el0
on arm64). Affected timestamps reflect cycle counter related values
since init (usually machine power-on or virtual machine start) instead
of time from the kernel's timekeeping initialization. This results in
a discontinuity in the printk timestamp values, one time, when
kernel timekeeping starts.

Signed-off-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
---
V5 -> V4
  Rationale: single point of change hack for printk.
  It provides a feature for kernel hackers willing to profiling the early boot
  with a basic printk approach (rather than using HW monitors which might not
  be available or immediately available). Thus, it is a first-look or a last
  resort hack profiling feature. Something that isn't good to spread around
  the kernel sources tree and it is fine to have into a single header file.
V3 -> V4
  Replace config vars with single one: CONFIG_EARLY_CYCLES_KHZ
  Replace runtime calibration with static config variable
  Remove reference to get_cycles()
  Add support for RISCV platforms
V2 -> V3
  Default CONFIG option to 'n'
  Move more code into early_times.h (reduce ifdefs in init/main.c)
  Use match64 helper routines
  Use cycles_t instead of u64 type
  Add #defines for EARLY_CYCLES_BIT and EARLY_CYCLES_MASK
  Invert if logic in adjust_early_ts()
V1 -> V2
  Remove calibration CONFIG vars
  Add 'depends on' to restrict arches (to handle ppc bug)
  Add early_ts_offset to avoid discontinuity
  Save cycles in ts_nsec, and convert on output
  Move conditional code to include file (early_times.h>

diff -pruN /dev/null kernel/printk/early_times.h
new file mode 100644
index 000000000000..82bacfd0e26b
--- /dev/null
+++ kernel/printk/early_times.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _EARLY_TIMES_H
+#define _EARLY_TIMES_H
+
+#include <linux/timekeeping.h>
+
+/*
+ * Fencing isn't optional here, otherwise unreliable values displaying
+ */
+#if defined(CONFIG_ARM64)
+		#include <asm/sysreg.h>
+		#define __early_raw_cycles ({ u64 val; \
+		    asm volatile("isb; mrs %0, cntvct_el0" : "=r"(val)); val; })
+#elif defined(CONFIG_X86_64)
+		#define __early_raw_cycles ({ u64 val; \
+		    asm volatile("lfence; rdtsc; shl $32, %%rdx; or %%rdx, %%rax" \
+		        : "=a"(val) : : "rdx"); val; })
+#elif defined(CONFIG_RISCV_TIMER)
+		#define __early_raw_cycles ({ u64 val; \
+		    asm volatile("fence; rdtime %0" : "=r"(val)); val; })
+#else
+		#define __early_raw_cycles 0
+#endif
+
+#endif /* _EARLY_TIMES_H */
diff --git a/init/Kconfig b/init/Kconfig
index 7484cd703bc1..40c3123c2c27 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -792,6 +792,26 @@ config IKHEADERS
 	  or similar programs.  If you build the headers as a module, a module called
 	  kheaders.ko is built which can be loaded on-demand to get access to headers.
 
+config EARLY_BOOT_TIMINGS
+	int "Early boot printk shows times in raw cycle counter style"
+	default 0
+	depends on PRINTK
+	depends on ARM64 || X86_64 || RISCV_TIMER
+	help
+	  Boolean value, disabled by default.
+
+	  Set this to provide cycles information for printks in early boot
+	  (before the start of kernel timekeeping), that would otherwise
+	  show as 0. Profiling by relative monotonic values, not time. 
+
+	  Note that this causes the kernel to show, for some early printks,
+	  cycles that are relative to processor power on, instead of
+	  relative to the start of kernel timekeeping.  When kernel
+	  timekeeping starts, the timestamps values reset, causing
+	  a discontinuity in the timestamp values.
+
+	  If unsure, keep it disabled as per its default.
+
 config LOG_BUF_SHIFT
 	int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
 	range 12 25
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0323149548f6..ddeab81f04ef 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2294,6 +2295,8 @@ int vprintk_store(int facility, int level,
 	 * timestamp with respect to the caller.
 	 */
 	ts_nsec = local_clock();
 
+#if CONFIG_EARLY_BOOT_TIMINGS
+#include "early_times.h"
+		/*
+		 * Very few developers are using this feature and they're expecting to deal
+		 * with it as a single point of change hack to be further customised by them.
+		 * The right shift by 2^10 is a raw extimation to provide 6-figure within the
+		 * first second when the kernel internal cycle/nS calibration isn't ready yet.
+		 */
+		if (unlikely(!ts_nsec))
+			ts_nsec = __early_raw_cycles >> 10;
+#endif
+
 	caller_id = printk_caller_id();
 
-- 
2.43.0

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

Follow up V5 integrated into kdev: uChaos supports _USE_RAW_CYCLES in
new v0.6.5:

~> https://github.com/robang74/uchaosys/commit/e48de8f

[    0.183957] Linux version 5.15.202 (roberto@x280) (x86_64-linux-musl-gcc
               (GCC) 14.3.0, GNU ld (GNU Binutils) 2.44) #1 Wed A6
[    0.183969] Command line: HOST=x86_64 root=/dev/ram0 init=/init
               console=ttyS0,115200n8 net.ifnames=0 nokaslr
[    0.183972] KERNEL supported cpus:
[    0.183973]   Intel GenuineIntel
[    0.183975]   AMD AuthenticAMD
[    0.184138] BIOS-provided physical RAM map:
[    0.184140] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.184144] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.184147] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.184149] BIOS-e820: [mem 0x0000000000100000-0x0000000001fdefff] usable
[    0.184152] BIOS-e820: [mem 0x0000000001fdf000-0x0000000001ffffff] reserved
[    0.184154] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
[    0.184157] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.184159] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[    0.184161] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[    0.184207] NX (Execute Disable) protection: active
[    0.184214] Hypervisor detected: KVM
[    0.184218] kvm-clock: Using msrs 4b564d01 and 4b564d00
[    0.184241] kvm-clock: cpu 0, msr bac001, primary cpu clock
--------- time skew here ---------
[    0.000001] kvm-clock: using sched offset of 55985760 cycles
[    0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff
               max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[    0.000005] tsc: Detected 1896.002 MHz processor
[    0.000324] last_pfn = 0x1fdf max_arch_pfn = 0x400000000
[............]
[    0.235538] uchaos: Init mts 4096B access x7 times: 115 < 196.3 > 594 uP

without _USE_RAW_CYCLES:

[    0.245907] uchaos: Init mts 4096B access x7 times: 64 < 134.4 > 322 uS

Cheers,
-- 
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Geert Uytterhoeven]

Hi Roberto,

On Wed, 15 Apr 2026 at 11:20, Roberto A. Foglietta
<roberto.foglietta@gmail.com> wrote:
> On Wed, 15 Apr 2026 at 02:19, Roberto A. Foglietta
> <roberto.foglietta@gmail.com> wrote:
> >
> > On Wed, 15 Apr 2026 at 00:38, Thomas Gleixner <tglx@kernel.org> wrote:
> > >
> > > On Fri, Apr 10 2026 at 14:37, Tim Bird wrote:
> > > > +
> > > > +#include <linux/timekeeping.h>
> > > > +#ifdef CONFIG_ARM64
> > > > +#include <asm/sysreg.h>
> > > > +#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.
> >
> > This translates in practice in early_unsafe_cycles() various
> > instances, one for each architecture supported. Even better a macro
> > for each architecture like this example below (untested code, just for
> > exemplification):
> >
> >   ts_nsec = local_clock();
> > #ifdef CONFIG_EARLY_CYCLES_KHZ
> > #if defined(CONFIG_ARM64)
> > #include <asm/sysreg.h>
> > #define early_unsafe_cycles read_sysreg(cntvct_el0);
> > #elif defined(CONFIG_X86_64)
> > #define early_unsafe_cycles rdtsc()
> > #elif defined(CONFIG_RISCV_TIMER)
> > #define early_unsafe_cycles ({ u64 val; asm volatile("rdtime %0" :
> > "=r"(val)); val; })
> > #else
> > #define early_unsafe_cycles 0
> > #endif
> > + if (unlikely(!ts_nsec))
> > + ts_nsec = early_times_ns();
> >  #endif // CONFIG_EARLY_CYCLES_KHZ
> >   caller_id = printk_caller_id();
> >
> > While keeping architectures separate is for abstraction layer best
> > practice, in very specific cases abstraction can be a meaningless
> > concept or much less important than having a single file for a single
> > feature (the complementary way of organising stuff). Because in Linux
> > the abstraction layer approach applies for architectures, the gap
> > between aesthetic and a specific case like an early boot macros set
> > hack for debugging is to clarify the exception from the general rule
> > in the header itself.
>
> IMHO, this patch (upstreamed or not) is for a few hackers and it is
> not even a tool but a first-outlook or last-resort hack. Therefore the
> single point of change that makes sense against spreading stuff that
> is supposed to be further hacked isn't the correct approach. The
> debate can be about upstreaming this kind of changes, and IMHO this
> one still has a sense to be upstreamed among debug features.
>
> I am attaching the path for just sake of independence storage (due my
> project github repo linked before is naturally subject to arbitrary
> changes by me). It is not supposed to be applied as-is (and probably
> cannot be applied anyway) and the patch has been written by hands on a
> keyboard. Gemini was used for retrieving information (in a smart man 3
> command style) and to collect the ASM code and its fencing.
>
> So the main question is: does this v5 suggested approach bridge the
> 1-single-point-of-change practical needs with the aim of keeping the
> source three? If yes then a V6 is worth being developed to provide the
> functionality and propose the upstream (I do not bet in good at the
> first write but on resolving the contrast/debate THEN delivery).
>
> Best regards, R-

Thanks for your patch!

> --- /dev/null
> +++ kernel/printk/early_times.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _EARLY_TIMES_H
> +#define _EARLY_TIMES_H
> +
> +#include <linux/timekeeping.h>
> +
> +/*
> + * Fencing isn't optional here, otherwise unreliable values displaying
> + */
> +#if defined(CONFIG_ARM64)
> +             #include <asm/sysreg.h>
> +             #define __early_raw_cycles ({ u64 val; \
> +                 asm volatile("isb; mrs %0, cntvct_el0" : "=r"(val)); val; })
> +#elif defined(CONFIG_X86_64)
> +             #define __early_raw_cycles ({ u64 val; \
> +                 asm volatile("lfence; rdtsc; shl $32, %%rdx; or %%rdx, %%rax" \
> +                     : "=a"(val) : : "rdx"); val; })
> +#elif defined(CONFIG_RISCV_TIMER)
> +             #define __early_raw_cycles ({ u64 val; \
> +                 asm volatile("fence; rdtime %0" : "=r"(val)); val; })
> +#else

All of these should be handled in arch/*/include/asm/early_times.h...

> +             #define __early_raw_cycles 0

... while this should be in include/asm-generic/early_times.h.

> +#endif
> +
> +#endif /* _EARLY_TIMES_H */

> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2294,6 +2295,8 @@ int vprintk_store(int facility, int level,
>        * timestamp with respect to the caller.
>        */
>       ts_nsec = local_clock();
>
> +#if CONFIG_EARLY_BOOT_TIMINGS
> +#include "early_times.h"
> +             /*
> +              * Very few developers are using this feature and they're expecting to deal
> +              * with it as a single point of change hack to be further customised by them.
> +              * The right shift by 2^10 is a raw extimation to provide 6-figure within the
> +              * first second when the kernel internal cycle/nS calibration isn't ready yet.
> +              */
> +             if (unlikely(!ts_nsec))
> +                     ts_nsec = __early_raw_cycles >> 10;

As there can be lots of variation in the granularity of early timers,
I think the shift should be moved in the arch-specific __early_raw_cycles,
so it is only done when useful.


> +#endif

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

[-- Attachment #1: Type: text/plain, Size: 5067 bytes --]

On Wed, 15 Apr 2026 at 20:41, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Roberto,
...
> Thanks for your patch!
>
> > --- /dev/null
> > +++ kernel/printk/early_times.h
> > @@ -0,0 +1,26 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#ifndef _EARLY_TIMES_H
> > +#define _EARLY_TIMES_H
> > +
> > +#include <linux/timekeeping.h>
> > +
> > +/*
> > + * Fencing isn't optional here, otherwise unreliable values displaying
> > + */
> > +#if defined(CONFIG_ARM64)
> > +             #include <asm/sysreg.h>
> > +             #define __early_raw_cycles ({ u64 val; \
> > +                 asm volatile("isb; mrs %0, cntvct_el0" : "=r"(val)); val; })
> > +#elif defined(CONFIG_X86_64)
> > +             #define __early_raw_cycles ({ u64 val; \
> > +                 asm volatile("lfence; rdtsc; shl $32, %%rdx; or %%rdx, %%rax" \
> > +                     : "=a"(val) : : "rdx"); val; })
> > +#elif defined(CONFIG_RISCV_TIMER)
> > +             #define __early_raw_cycles ({ u64 val; \
> > +                 asm volatile("fence; rdtime %0" : "=r"(val)); val; })
> > +#else
>
> All of these should be handled in arch/*/include/asm/early_times.h...
>
> > +             #define __early_raw_cycles 0
>
> ... while this should be in include/asm-generic/early_times.h.

In the last release of the patch, I decided to stick with the "single
point of hacking" approach

https://github.com/robang74/uchaosys/blob/v069/cnfg/printk-early-boot-timestamps-hack-v5.patch

and I developed it in a way that can be proposed in such "exceptional
way" for this very specific case:

+#if CONFIG_PRINTK_EARLY_BOOT_TIMINGS
+#include "early_times.h"
+ /*
+ * Very few developers are using this feature and they're expecting to deal
+ * with it as a single point of change hack to be further customised by them.
+ */
+ if (unlikely(!ts_nsec))
+ ts_nsec = __early_raw_cycles;
+#endif

As you can see the include uses double quotes to indicate that the
header is local and it is not supposed to belong to the formal three:
it is where everyone of us will put it when we are going to do dirty
tricks to reach somewhat result, in the same folder of the printk.c,
out-of-the-three.

Why is this a very special case?

- First of all because just a variable is provided by the macros set.
No hypothesis, just a variable as-is because most of the few users
that might be interested in are going to watch HOW the relative
sequences of events are happening. Moreover, there is no reason to
pretend (sell) a timestamp when the timestamp sub-system is not ready
to provide that feature: fairness first, by clarity. Previously the
time skew was from zeros and something, now from two different ways of
tagging the printk.

- Second, because there is a very limited use of it due to almost
immediate timestamp readiness. Therefore those who are interested,
they were hacking with very LOW level stuff (or BIOS for those are
constraint but that evilness in x86 arch). For those people the ASM
code is fine and it is very useful to have it in the same place. And
it is in the interest of those who maintain the kernel that those
people have a single point of hack for the major arch available.
Easier is for them to test different arches, far more improbable an
under-tested patch will reach a proposal upstream stage... and trust
me about "under-tested" because I am an expert on that field... ;-)
LOL

- Third, because every assumption has been removed, even the basics
>>10 shifts. Just something that appears as a variable emerging from a
local header and these two things together should ring some bells in
the head of those who have a little experience of firmware / embedded.
Few constructs are more vicious than macros that resemble variables...
;-)

> > +             if (unlikely(!ts_nsec))
> > +                     ts_nsec = __early_raw_cycles >> 10;
>
> As there can be lots of variation in the granularity of early timers,
> I think the shift should be moved in the arch-specific __early_raw_cycles,
> so it is only done when useful.
>

I am attaching the matured V5 patch that I tested against the 5.15.202
LTS kernel. Please, sit on the approach -- include"local-stuff.h" --
and let your judgement get soothed by time and PoVs. For sure one
change is probably a necessity, moving the Kconfig part into the DEBUG
section from the INIT where it stays by now. However, moving a feature
around the menuconfig is the last and less effort change in a TODO
list.

For sake of completeness, I am attaching the V5 matured patch. Will it
be refused because of its approach? Fine, at least the idea of that
approach has a patch that can be applied to something and people can
give it a try. Which add a practical degree of judgemental because
usually we are attracted by the beauty of perfection and purity,
something that Franco Battiato entitled "Inneres Auge" (a call from
above) but as complementary we are also keen to fall in love for those
bare-simple dirty-practical solution... in the same sense that song
was intending with a convoluted and educated paraphrase... LOL

Cheers, R-

[-- Attachment #2: printk-early-boot-timestamps-hack-v5.patch --]
[-- Type: text/x-patch, Size: 5376 bytes --]

This is a heavily "refactored by hands" patch for Linux Kernel 5.15.202 LTS
trying to solve the source tree janitoring vs 1-single place hack for hackers
in need for a simple-bare profiling tool and based on the patch V4 submitted by

From: Tim Bird <tim.bird@sony.com>
Subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
Date: Fri, 10 Apr 2026 14:37:41 -0600
Message-ID: <20260410203741.997410-2-tim.bird@sony.com>

During early boot, printk timestamps are reported as zero before
kernel timekeeping starts (i.e. before time_init()). This hinders
boot-time optimization efforts. This period ranges from 17 to 1700
milliseconds on different embedded machines running Linux.

Add support for early timestamps based on processor cycle-generators
that need no kernel initialization.This feature isn't intended for a 
generic distro kernels but for temporary use during kernel development
and boot-time research and optimization by kernel hackers only.

This yields non-zero timestamps for printks from the very start
of kernel execution. The timestamps are relative to the start of
an architecture-specific counter (e.g. tsc on x86_64 and cntvct_el0
on arm64). Affected timestamps reflect cycle counter related values
since init (usually machine power-on or virtual machine start) instead
of time from the kernel's timekeeping initialization. This results in
a discontinuity in the printk timestamp values, one time, when
kernel timekeeping starts.

Signed-off-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
---
V5 -> V4
  Rationale: single point of change hack for printk. Code rewritten, entirely.
  It provides a feature for kernel hackers willing to profiling the early boot
  with a basic printk approach (rather than using HW monitors which might not
  be available or immediately available). Thus, it is a first-look or a last
  resort hack profiling feature. Something that isn't good to spread around
  the kernel sources tree and it is fine to have into a single header file.
V3 -> V4
  Replace config vars with single one: CONFIG_EARLY_CYCLES_KHZ
  Replace runtime calibration with static config variable
  Remove reference to get_cycles()
  Add support for RISCV platforms
V2 -> V3
  Default CONFIG option to 'n'
  Move more code into early_times.h (reduce ifdefs in init/main.c)
  Use match64 helper routines
  Use cycles_t instead of u64 type
  Add #defines for EARLY_CYCLES_BIT and EARLY_CYCLES_MASK
  Invert if logic in adjust_early_ts()
V1 -> V2
  Remove calibration CONFIG vars
  Add 'depends on' to restrict arches (to handle ppc bug)
  Add early_ts_offset to avoid discontinuity
  Save cycles in ts_nsec, and convert on output
  Move conditional code to include file early_times.h

--- a/init/Kconfig	2026-04-15 11:34:05.823433712 +0200
+++ b/init/Kconfig	2026-04-15 11:36:12.703334604 +0200
@@ -833,6 +833,27 @@ config PRINTK_INDEX
 
 	  There is no additional runtime cost to printk with this enabled.
 
+config PRINTK_EARLY_BOOT_TIMINGS
+	bool "Early boot printk shows times in raw cycle counter style"
+	default 0
+	depends on PRINTK
+	depends on ARM64 || X86_64 || RISCV_TIMER
+	select PRINTK_TIME
+	help
+	  Boolean value, disabled by default.
+
+	  Set this to provide cycles information for printks in early boot
+	  (before the start of kernel timekeeping), that would otherwise
+	  show as 0. Profiling by relative monotonic values, not time.
+
+	  Note that this causes the kernel to show, for some early printks,
+	  cycles that are relative to processor power on, instead of
+	  relative to the start of kernel timekeeping. When kernel
+	  timekeeping starts, the timestamps values reset, causing
+	  a discontinuity in the timestamp values.
+
+	  If unsure, keep it disabled as per its default.
+
 #
 # Architectures with an unreliable sched_clock() should select this:
 #
--- /dev/null	2026-04-10 15:35:49.659741644 +0200
+++ b/kernel/printk/early_times.h	2026-04-15 11:32:49.786728602 +0200
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _EARLY_TIMES_H
+#define _EARLY_TIMES_H
+
+#include <linux/timekeeping.h>
+
+/*
+ * Fencing isn't optional here, otherwise unreliable values displaying
+ */
+#if defined(CONFIG_ARM64)
+	#include <asm/sysreg.h>
+	#define __early_raw_cycles ({ u64 val; \
+		asm volatile("isb; mrs %0, cntvct_el0" : "=r"(val)); val; })
+#elif defined(CONFIG_X86_64)
+	#define __early_raw_cycles ({ u64 val; \
+		asm volatile("lfence; rdtsc; shl $32, %%rdx; or %%rdx, %%rax" \
+			: "=a"(val) : : "rdx"); val; })
+#elif defined(CONFIG_RISCV_TIMER)
+	#define __early_raw_cycles ({ u64 val; \
+		asm volatile("fence; rdtime %0" : "=r"(val)); val; })
+#else
+	#define __early_raw_cycles 0
+#endif
+
+#endif /* _EARLY_TIMES_H */
--- a/kernel/printk/printk.c	2026-04-15 11:39:55.372066802 +0200
+++ b/kernel/printk/printk.c	2026-04-15 11:39:33.458953582 +0200
@@ -2151,6 +2151,16 @@ int vprintk_store(int facility, int leve
 	 */
 	ts_nsec = local_clock();
 
+#if CONFIG_PRINTK_EARLY_BOOT_TIMINGS
+#include "early_times.h"
+	/*
+	 * Very few developers are using this feature and they're expecting to deal
+	 * with it as a single point of change hack to be further customised by them.
+	 */
+	if (unlikely(!ts_nsec))
+		ts_nsec = __early_raw_cycles;
+#endif
+
 	if (!printk_enter_irqsave(recursion_ptr, irqflags))
 		return 0;
 

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Thomas Gleixner]

On Wed, Apr 15 2026 at 02:19, Roberto A. Foglietta wrote:
> While keeping architectures separate is for abstraction layer best
> practice, in very specific cases abstraction can be a meaningless
> concept or much less important than having a single file for a single
> feature (the complementary way of organising stuff). Because in Linux
> the abstraction layer approach applies for architectures, the gap
> between aesthetic and a specific case like an early boot macros set
> hack for debugging is to clarify the exception from the general rule
> in the header itself.

Please spare me this AI bullsh*t.

There is absolutely ZERO justification for this at all. End of story.

Thanks,

        tglx

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Wed, 15 Apr 2026 at 23:30, Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Wed, Apr 15 2026 at 02:19, Roberto A. Foglietta wrote:
> > While keeping architectures separate is for abstraction layer best
> > practice, in very specific cases abstraction can be a meaningless
> > concept or much less important than having a single file for a single
> > feature (the complementary way of organising stuff). Because in Linux
> > the abstraction layer approach applies for architectures, the gap
> > between aesthetic and a specific case like an early boot macros set
> > hack for debugging is to clarify the exception from the general rule
> > in the header itself.
>
> Please spare me this AI bullsh*t.
>
> There is absolutely ZERO justification for this at all. End of story.
>

V5

A single file with the essential for hacking the early boot,
activatable by debug export menuconfig, an #include "locale.h" in the
same folder in which printk.c lives and when the developer did every
insanity to make things work, rm -f $file and push all. No one in
production nor users will complain that there is a Kconfig debug
expert feature potentially broken. No one among kernel janitors will
need to care about an isolated file in which the whole future changes
acceptable are extending the framework to another architecture
maintaining the essential simplicity of reading a register protected
by a fence to grant WHEN it would be read.

! AI bullsh*t.

Beware of activating debug expert options, crying isn't allowed in
adulthood... What you call bullshit is simplicity for both the worlds.
The speed at which I am writing about things you cannot compute as
fast as I can write, has nothing to do with AI. Try to compile your
metacognition.ko with -O2 option instead of -xxs... LOL (yes this last
paragraph is a bullsh*t, so we can have a comparison between the
prototype and the instance of the BS class/template LOLx2).

Best regards, R-

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Wed, 15 Apr 2026 at 23:57, Roberto A. Foglietta
<roberto.foglietta@gmail.com> wrote:
>

[...]

> V5
>
> A single file with the essential for hacking the early boot,

early_times.h -- it means before every feature offered by the kernel
is available or 100% trustable, thus ASM because it is also supposed
to fix what is broken in the kernel thus using the kernel macros isn't
the correct way to do so. Early times means before the kernel, thus
also out-of-it-three or feature support. Them asm (isb) sounds too
drastic or not enough for "exhotic" arm arch? It is a template to
start with, not a working part of the kernel. When the kernel works,
!0 == true is true.

The concept remains the same: a register counter read protected by
fencing. Not more, not less than the essential. And a bucket
out-of-the-three as a starting point **before** the kernel is ready or
fixed. Written in this way, does it sound more reasonable?

Best regards, R-

RE: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Bird, Tim]

> -----Original Message-----
> From: Roberto A. Foglietta <roberto.foglietta@gmail.com>
> On Wed, 15 Apr 2026 at 23:57, Roberto A. Foglietta
> <roberto.foglietta@gmail.com> wrote:
> >
> 
> [...]
> 
> > V5
> >
> > A single file with the essential for hacking the early boot,
> 
> early_times.h -- it means before every feature offered by the kernel
> is available or 100% trustable, thus ASM because it is also supposed
> to fix what is broken in the kernel thus using the kernel macros isn't
> the correct way to do so. Early times means before the kernel, thus
> also out-of-it-three or feature support. Them asm (isb) sounds too
> drastic or not enough for "exhotic" arm arch? It is a template to
> start with, not a working part of the kernel. When the kernel works,
> !0 == true is true.

Roberto,

I appreciate your work to address deficiencies in the proposed
patch, but I don't follow the above paragraph.  There's nothing
"broken" about the kernel to fix, just an opportunity to
instrument more code during bootup than is currently supported.

I think Thomas has demonstrated that this does not have a lot of value
for x86_64 platforms (where the blind spot is already quite small), but
on ARM64 and RISCV I think there is some value to developers working
on boot time.
 
> The concept remains the same: a register counter read protected by
> fencing. Not more, not less than the essential. And a bucket
> out-of-the-three as a starting point **before** the kernel is ready or
> fixed. Written in this way, does it sound more reasonable?

I don't know what "bucket out-of-the-three" means?

Thomas has expressed concerns about a number of issues with the latest v4
patch which I haven't responded to yet.  I was trying to reproduce the bug
report with clang compilation (reported by 0-day on Sunday), and so far have
not been able to. I have a proposed solution for that, and for other feedback received.
But I hesitate to make a V5 patch before I reproduce the problem on my system
and verify my fix for that bug report.

Honestly, given how strongly Thomas feels about some of the items, this may end
up not being accepted upstream.  But rather than give up at this point, I'd like to
at least address all feedback received and issue one more patch for consideration.
If it doesn't get accepted, I will have received some valuable feedback which will
help make the (out-of-tree) patch as general and as conformant with kernel standards
as possible, which is useful.

With regard to that, I'll note that sprinkling early_unsafe_cycles() definitions
around arch directories will make an out-of-tree patch less likely to apply, so
there's some tension in how the patch should be structured for upstream
acceptance and out-of-tree maintenance.

For those interested, I'm trying to address the following:
 - use of arch-specific ifdefs in generic headers
 - warning about divide by zero
    - there are multiple ways to address this, and I want to use the
      most maintainable (least source-code-disrupting and confusing)
      one going forward.  I liked David Laight's solution (val?:1), but it may not
      be needed with other changes I plan to make.
 - use of mul_u64_u32_div() for math, so that 32-bit systems which
   might use this in the future are supported seamlessly
     - I thought the compiler would do better with optimizing the math
       (with all the values being constants except for the cycles value).
       However, testing on different platforms (and different cycles KHz settings)
       has given mixed results.
     - Examination of the assembly code produced seems to indicate that
       using mul_u64_u32_div() is likely the best option.
     - Given that this feature is not intended to be used in production kernels,
        I don't think that optimizing the instruction sequence for something that
        occurs less than a hundred times in early boot (the upper bound on existing
        blind spot printks that I've seen) will matter, for instrumentation purposes.
        The amount of cycles that printk uses for message buffering, formatting and
        output completely swamps the cost of the cycles-to-nanoseconds conversion.
 - use of NSEC_ prefix instead of NS_ prefix
 - addition of fences to the assembly for reading the cycle-counter.
    - I need to consider whether these are needed or not.  I believe you said that
      you got mangled values without them.  Can you confirm that?

Thanks again for your proposals and feedback.  And thanks for testing the code out
in different environments.
 -- Tim

P.S. Thomas - I appreciate your additional feedback, and will work to address it.  Sorry
I haven't responded sooner.

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Thu, 16 Apr 2026 at 01:12, Bird, Tim <Tim.Bird@sony.com> wrote:
>
> > -----Original Message-----
> > From: Roberto A. Foglietta <roberto.foglietta@gmail.com>
> > On Wed, 15 Apr 2026 at 23:57, Roberto A. Foglietta
> > <roberto.foglietta@gmail.com> wrote:
> > >
> >
> > [...]
> >
> > > V5
> > >
> > > A single file with the essential for hacking the early boot,
> >
> > early_times.h -- it means before every feature offered by the kernel
> > is available or 100% trustable, thus ASM because it is also supposed
> > to fix what is broken in the kernel thus using the kernel macros isn't
> > the correct way to do so. Early times means before the kernel, thus
> > also out-of-it-three or feature support. Them asm (isb) sounds too
> > drastic or not enough for "exhotic" arm arch? It is a template to
> > start with, not a working part of the kernel. When the kernel works,
> > !0 == true is true.
>
> Roberto,
>
> I appreciate your work to address deficiencies in the proposed
> patch, but I don't follow the above paragraph.  There's nothing
> "broken" about the kernel to fix, just an opportunity to
> instrument more code during bootup than is currently supported.
>
> I think Thomas has demonstrated that this does not have a lot of value
> for x86_64 platforms (where the blind spot is already quite small), but
> on ARM64 and RISCV I think there is some value to developers working
> on boot time.
>

My printouts about x86_64 confirmed, in such a platform the timekeeper
subsystem is almost instantaneously ready.


> > The concept remains the same: a register counter read protected by
> > fencing. Not more, not less than the essential. And a bucket
> > out-of-the-three as a starting point **before** the kernel is ready or
> > fixed. Written in this way, does it sound more reasonable?
>
> I don't know what "bucket out-of-the-three" means?

It is not clear to me what you are trying to achieve with V4 but that
patch was WRONG in principle, in concept and in implementation and
this sparked the debate, nothing else. Plus, there is no bug to fix,
apart from a regression that V4 would have introduced. The correct
approach is the V5 that I rewrote for you:

- https://raw.githubusercontent.com/robang74/uchaosys/e48de8fde/cnfg/printk-early-boot-timestamps-hack-v5.patch

That constitutes an entry point in which every developer can include
their own code. Please, follow that canvas especially if your company
is supporting your upstream campaign with a budget. So, lately your
code could silently be stripped away in favour of a more general
approach. ARM didn't arrive in Linux yesterday and I would be
surprised that you are trying to solve an issue that bothers a lot of
people. Anyway, I can be wrong, but 1700 ms to reach the internal
clock settings isn't sane.

The general approach is having an "early times" entry point in which
people that are porting the kernel on a new silicon can have a "ready
to go" way to start in dealing with printk (thus console output) and
timings (the two things need to start with) after they managed to
complete the boot (which isn't always granted and in some cases it is
a luxury not a commodity).

>
> Thomas has expressed concerns about a number of issues with the latest v4
> patch which I haven't responded to yet.  I was trying to reproduce the bug
> report with clang compilation (reported by 0-day on Sunday), and so far have
> not been able to. I have a proposed solution for that, and for other feedback received.
> But I hesitate to make a V5 patch before I reproduce the problem on my system
> and verify my fix for that bug report.

Please, also consider the feedback you received about 0-division: you
might have a problem sitting between the chair and the screen of your
system... ;-) LOL

Usually, we **humans developers** are such a problem >99.9% times when
gcc complains.

>
> Honestly, given how strongly Thomas feels about some of the items, this may end
> up not being accepted upstream.  But rather than give up at this point, I'd like to
> at least address all feedback received and issue one more patch for consideration.
> If it doesn't get accepted, I will have received some valuable feedback which will
> help make the (out-of-tree) patch as general and as conformant with kernel standards
> as possible, which is useful.

Take my V5 patch, apply (or adapt to apply if your kernel version
differs from 5.15) and then start to put your code into early-times.h
when you completed your investigation, you will appreciate the great
advantage of fix the problem with a single command line operation in
your local source tree: rm -f early-times.h

Best regards,

--
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

Hi,

In attachment the V6 of the patch, and these are the changes since Tim
proposed it:

V5 -> V6
  Feature moved in the proper menu place, immediately after:
  Kernel hacking -> printk and dmesg options -> show timitng information printks
  Comments and descriptions more clearly indicate the aim and the limits of this
  patch and the related feature introduced by this patch.
V4 -> V5
  Rationale: single point of change hack for printk. Code rewritten, entirely.
  It provides a feature for kernel hackers willing to profiling the early boot
  with a basic printk approach (rather than using HW monitors which might not
  be available or immediately available). Thus, it is a first-look or a last
  resort hack profiling feature. Something that isn't good to spread around
  the kernel sources tree and it is fine to have into a single header file.

    cnfg/printk-early-boot-timestamps-hack-v6.patch: polishing, V6

    Pre-Kernel boot time (qemu, KVM, bios) is 0.251063 / 1.896 = 0.132 seconds

    [    0.250814] Linux version 5.15.202 (roberto@x280) (x86_64-linux-musl-gcc
                   (GCC) 14.3.0, GNU ld (GNU Binutils) 2.44) #1 Thu A6
    [    0.250820] Command line: HOST=x86_64 root=/dev/ram0 init=/init
                   console=ttyS0,115200n8 net.ifnames=0 nokaslr
    [    0.250823] KERNEL supported cpus:
    [    0.250824]   Intel GenuineIntel
    [    0.250826]   AMD AuthenticAMD
    [    0.250972] BIOS-provided physical RAM map:
    [    0.250973] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
    [    0.250978] BIOS-e820: [mem
0x000000000009fc00-0x000000000009ffff] reserved
    [    0.250981] BIOS-e820: [mem
0x00000000000f0000-0x00000000000fffff] reserved
    [    0.250983] BIOS-e820: [mem 0x0000000000100000-0x0000000001fdefff] usable
    [    0.250986] BIOS-e820: [mem
0x0000000001fdf000-0x0000000001ffffff] reserved
    [    0.250989] BIOS-e820: [mem
0x00000000b0000000-0x00000000bfffffff] reserved
    [    0.250991] BIOS-e820: [mem
0x00000000fed1c000-0x00000000fed1ffff] reserved
    [    0.250994] BIOS-e820: [mem
0x00000000feffc000-0x00000000feffffff] reserved
    [    0.250996] BIOS-e820: [mem
0x00000000fffc0000-0x00000000ffffffff] reserved
    [    0.251043] NX (Execute Disable) protection: active
    [    0.251050] Hypervisor detected: KVM
    [    0.251053] kvm-clock: Using msrs 4b564d01 and 4b564d00
    [    0.251063] kvm-clock: cpu 0, msr bac001, primary cpu clock
    [    0.000001] kvm-clock: using sched offset of 56130848 cycles
    [    0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff
                   max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
    [    0.000005] tsc: Detected 1896.002 MHz processor

Best regards, R-

[-- Attachment #2: printk-early-boot-timestamps-hack-v6.patch --]
[-- Type: text/x-patch, Size: 5876 bytes --]

This is a heavily "refactored by hands" patch for Linux Kernel 5.15.202 LTS
trying to solve the source tree janitoring vs 1-single place hack for hackers
in need for a simple-bare profiling tool and based on the patch V4 submitted by

From: Tim Bird <tim.bird@sony.com>
Subject: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot
Date: Fri, 10 Apr 2026 14:37:41 -0600
Message-ID: <20260410203741.997410-2-tim.bird@sony.com>

During early boot, printk timestamps are reported as zero before
kernel timekeeping starts (i.e. before time_init()). This hinders
boot-time optimization efforts. This period ranges from 17 to 1700
milliseconds on different embedded machines running Linux.

Add support for early timestamps based on processor cycle-generators
that need no kernel initialization.This feature isn't intended for a 
generic distro kernels but for temporary use during kernel development
and boot-time research and optimization by kernel hackers only.

This yields non-zero timestamps for printks from the very start
of kernel execution. The timestamps are relative to the start of
an architecture-specific counter (e.g. tsc on x86_64 and cntvct_el0
on arm64). Affected timestamps reflect cycle counter related values
since init (usually machine power-on or virtual machine start) instead
of time from the kernel's timekeeping initialization. This results in
a discontinuity in the printk timestamp values, one time, when
kernel timekeeping starts.

Signed-off-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
---
V5 -> V6
  Feature moved in the proper menu place, immediately after:
  Kernel hacking -> printk and dmesg options -> show timitng information printks
  Comments and descriptions more clearly indicate the aim and the limits of this
  patch and the related feature introduced by this patch.
V4 -> V5
  Rationale: single point of change hack for printk. Code rewritten, entirely.
  It provides a feature for kernel hackers willing to profiling the early boot
  with a basic printk approach (rather than using HW monitors which might not
  be available or immediately available). Thus, it is a first-look or a last
  resort hack profiling feature. Something that isn't good to spread around
  the kernel sources tree and it is fine to have into a single header file.
V3 -> V4
  Replace config vars with single one: CONFIG_EARLY_CYCLES_KHZ
  Replace runtime calibration with static config variable
  Remove reference to get_cycles()
  Add support for RISCV platforms
V2 -> V3
  Default CONFIG option to 'n'
  Move more code into early_times.h (reduce ifdefs in init/main.c)
  Use match64 helper routines
  Use cycles_t instead of u64 type
  Add #defines for EARLY_CYCLES_BIT and EARLY_CYCLES_MASK
  Invert if logic in adjust_early_ts()
V1 -> V2
  Remove calibration CONFIG vars
  Add 'depends on' to restrict arches (to handle ppc bug)
  Add early_ts_offset to avoid discontinuity
  Save cycles in ts_nsec, and convert on output
  Move conditional code to include file early_times.h

--- a/lib/Kconfig.debug	2026-04-16 08:52:44.771618719 +0200
+++ b/lib/Kconfig.debug	2026-04-16 08:55:08.358941989 +0200
@@ -18,6 +18,29 @@ config PRINTK_TIME
 	  The behavior is also controlled by the kernel command line
 	  parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
 
+config PRINTK_EARLY_BOOT_TIMINGS
+	bool "Early boot printk shows times in raw cycle counter style"
+	default 0
+	depends on PRINTK
+	depends on ARM64 || X86_64 || RISCV_TIMER
+	select PRINTK_TIME
+	help
+	  Boolean value, disabled by default.
+
+	  Set this option to provide cycles information for printks at early
+	  boot times (before the start of kernel timekeeping), that would
+	  otherwise show as 0.
+
+	  Useful for profiling by relative monotonic values, not time.
+
+	  Note that this causes the kernel to show, for some early printks,
+	  cycles that are relative to processor power on, instead of
+	  relative to the start of kernel timekeeping. When kernel
+	  timekeeping starts, the timestamps values reset, causing
+	  a discontinuity in the timestamp values.
+
+	  If unsure, say N.
+
 config PRINTK_CALLER
 	bool "Show caller information on printks"
 	depends on PRINTK
--- /dev/null	2026-04-10 15:35:49.659741644 +0200
+++ b/kernel/printk/early_times.h	2026-04-15 11:32:49.786728602 +0200
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _EARLY_TIMES_H
+#define _EARLY_TIMES_H
+
+#include <linux/timekeeping.h>
+
+/*
+ * Fencing isn't optional here, otherwise unreliable values displaying
+ */
+#if defined(CONFIG_ARM64)
+	#include <asm/sysreg.h>
+	#define __early_raw_cycles ({ u64 val; \
+		asm volatile("isb; mrs %0, cntvct_el0" : "=r"(val)); val; })
+#elif defined(CONFIG_X86_64)
+	#define __early_raw_cycles ({ u64 val; \
+		asm volatile("lfence; rdtsc; shl $32, %%rdx; or %%rdx, %%rax" \
+			: "=a"(val) : : "rdx"); val; })
+#elif defined(CONFIG_RISCV_TIMER)
+	#define __early_raw_cycles ({ u64 val; \
+		asm volatile("fence; rdtime %0" : "=r"(val)); val; })
+#else
+	#define __early_raw_cycles 0
+#endif
+
+#endif /* _EARLY_TIMES_H */
--- a/kernel/printk/printk.c	2026-04-15 11:39:55.372066802 +0200
+++ b/kernel/printk/printk.c	2026-04-15 11:39:33.458953582 +0200
@@ -2151,6 +2151,18 @@ int vprintk_store(int facility, int leve
 	 */
 	ts_nsec = local_clock();
 
+#if CONFIG_PRINTK_EARLY_BOOT_TIMINGS
+#include "early_times.h"
+	/*
+	 * Very few developers are going to use this feature and it is
+	 * expected they're able to deal with it as a single entry-point of
+	 * changes. An hack to be further customised by them for porting the
+	 * kernel on not-yet-supported silicon or bug fixing / optimisations.
+	 */
+	if (unlikely(!ts_nsec))
+		ts_nsec = __early_raw_cycles;
+#endif
+
 	if (!printk_enter_irqsave(recursion_ptr, irqflags))
 		return 0;
 

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Geert Uytterhoeven]

Hi Roberto,

On Thu, 16 Apr 2026 at 10:25, Roberto A. Foglietta
<roberto.foglietta@gmail.com> wrote:
> In attachment the V6 of the patch, and these are the changes since Tim
> proposed it:

Please no attachments, as it makes it much harder to read the patch,
and comment on it:

https://elixir.bootlin.com/linux/v7.0/source/Documentation/process/submitting-patches.rst#L278

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Thu, 16 Apr 2026 at 10:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Roberto,
>
> On Thu, 16 Apr 2026 at 10:25, Roberto A. Foglietta
> <roberto.foglietta@gmail.com> wrote:
> > In attachment the V6 of the patch, and these are the changes since Tim
> > proposed it:
>
> Please no attachments, as it makes it much harder to read the patch,
> and comment on it:

Thanks for having considered the patch.

>
> https://elixir.bootlin.com/linux/v7.0/source/Documentation/process/submitting-patches.rst#L278
>

Is this a link? ;-)

--> No MIME, no links, no compression, no attachments. Just plain text

You guys need a plugin for TUI e-mail readers/git-am that solves the
text/base64 attachments issue.

Seriously, someone should write it and write it in a manner that
kernel guys are happy to adopt/use it.

It will be a great relief for both the sides (senders, receivers)
because space/tab mismatch hurts as well.

While git-send requires some hard-to-grant precautions to not become a
serious trouble / headache.

Best regards, R-

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[David Laight]

On Thu, 16 Apr 2026 11:38:53 +0200
"Roberto A. Foglietta" <roberto.foglietta@gmail.com> wrote:

> On Thu, 16 Apr 2026 at 10:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Roberto,
> >
> > On Thu, 16 Apr 2026 at 10:25, Roberto A. Foglietta
> > <roberto.foglietta@gmail.com> wrote:  
> > > In attachment the V6 of the patch, and these are the changes since Tim
> > > proposed it:  
> >
> > Please no attachments, as it makes it much harder to read the patch,
> > and comment on it:  
> 
> Thanks for having considered the patch.
> 
> >
> > https://elixir.bootlin.com/linux/v7.0/source/Documentation/process/submitting-patches.rst#L278
> >  
> 
> Is this a link? ;-)
> 
> --> No MIME, no links, no compression, no attachments. Just plain text  
> 
> You guys need a plugin for TUI e-mail readers/git-am that solves the
> text/base64 attachments issue.

Eh?
Not the least of the problems is that you (typically) have to explicitly
open the attachment in order to actually read it.
If it is inline you can just scroll down and give it a quick scan.

Have you ever tried reading patch attachments with what might be the
most common MUA on everything except phones?
You actually have to save them somewhere before you can open them.

	David

> 
> Seriously, someone should write it and write it in a manner that
> kernel guys are happy to adopt/use it.
> 
> It will be a great relief for both the sides (senders, receivers)
> because space/tab mismatch hurts as well.
> 
> While git-send requires some hard-to-grant precautions to not become a
> serious trouble / headache.
> 
> Best regards, R-
> 

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Thu, 16 Apr 2026 at 12:52, David Laight <david.laight.linux@gmail.com> wrote:
>

>
> Eh?

Kids were playing for a prize, I was in charge of assigning THAT
specific prize and I already assigned it in november 2023. They
continued to play because they were not informed about the assignment,
not even the one who one got it (or possibly he did not tell anyone).
Kids have been misdirected for political goals using the Facebook
platform. We are NOT kids, we do not play to win a prize. We do stuff
because we are aware of what we are doing and when we do work, we
expect to be paid (or paid to sell, and we are also great in sales and
marketing if we want to).

We are seniors. Not granny, not kid. Senior. Is it clear the difference?

Technical stuff is signed with R- because humility, statements like
this are signed with the full name, because a man in flesh and blood
wrote it, not a geek not an AI, a senior wrote it and there is anymore
doubt that I am a senior like many others, also here.

A senior,
-- 
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Petr Mladek]

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 <linux/timekeeping.h>
> > +#ifdef CONFIG_ARM64
> > +#include <asm/sysreg.h>
> > +#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

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Fri, 17 Apr 2026 at 12:41, Petr Mladek <pmladek@suse.com> wrote:
>
...
> 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?

There are two different topics here and confusion arises from not
separating them:

1. Having a monotonic timestamp fully reliable and ASAP after the
kernel takes the control, is a great feature. Period.

2. Few people but relevant ones, those need to port the kernel on
prototypes that later will be products (hopefully).

The #1 goes in the kernel, following strictly the rules of the coding
/ janitoring. Period.

The #2 cannot go into the kernel tree but it is inheterly doomed to be
an out-of-tree entry point for "few people". Simply because it servers
those for which they are working "before" the kernel (early times, not
just about boot but kernel porting). In such a condition, the kernel
might oops soon after the boot without even reaching the timekeeper
calibration. As per first look or last resort, printing cycles (or any
other values as much as possible tight with the hardware) is the only
feasible approach.

A link (to this m-list repository) avoid repetitions, the V6 is much
better and more useful that a bunch of #ifdef / #else in the printk.c:

V6 ~> https://lkml.org/lkml/2026/4/16/441

How to settle down the debate about #1 and #2. Recognising that the #1
is a kernel feature, the #2 is a "before" the kernel thus out-of-three
approach for few but relevant people. Why offer to these "few but
relevant people" an entry point with essential directives, a fenced
read of a register, available for many arch in the same local header?
It costs almost nothing in terms of maintainability and provides a
universal way to face the same-old-issue of having something useful
rather than zero in early boot.

It costs almost nothing because it is essential and it is not supposed
to grow or be refined: essential is essential. Moreover, we cannot
develop for boards that did not exist yet, but essentials remain
valid, at least as a concept. It is clearly something out-of-the-three
because #include "early-times.h" and it is clearly something that it
is for advanced debugging and hacking (proper menuconfig placement),
thus not a feature but "essential as service".

Value (in terms of market)? Just a matter of perception: we know you
are out there, few and messy down in some portings, here you are our
2cents for you. In less modern terms: welcoming, as custom courtesy.
Is it relevant to add? Everyone that can port the kernel can do it in
their own way. It is relevant to recognise that #2 is not #1, anyway
even when #1 will solve the issue for every product out there.

Best regards, R-

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Steven Rostedt]

On Fri, 17 Apr 2026 13:46:12 +0200
"Roberto A. Foglietta" <roberto.foglietta@gmail.com> wrote:

> V6 ~> https://lkml.org/lkml/2026/4/16/441

Note, nobody uses lkml.org anymore as it is unreliable and slow. We've
been using lore for years.

  https://lore.kernel.org/all/CAJGKYO7==hZ3OnRNuG81j6rxH3y1gK8qB-orxxrDsc4pNFv=hQ@mail.gmail.com/

-- Steve

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Fri, 17 Apr 2026 at 18:11, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 17 Apr 2026 13:46:12 +0200
> "Roberto A. Foglietta" <roberto.foglietta@gmail.com> wrote:
>
> > V6 ~> https://lkml.org/lkml/2026/4/16/441
>
> Note, nobody uses lkml.org anymore as it is unreliable and slow. We've
> been using lore for years.
>
>   https://lore.kernel.org/all/CAJGKYO7==hZ3OnRNuG81j6rxH3y1gK8qB-orxxrDsc4pNFv=hQ@mail.gmail.com/
>
> -- Steve

... but the link is something as easy as a website, m-list code, date,
message id.

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Brian Masney]

Hi Petr,

On Fri, Apr 17, 2026 at 6:37 AM Petr Mladek <pmladek@suse.com> wrote:
>    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?

Thanks for the nice summary of the discussions so far. From the
standpoint of the boot speed work that I have done so far, the bogo
cycles would be good enough in my opinion. It would have identified
that I issue that I described earlier in this thread.

Regarding the message, I would put a firmer message similar to what's
in drivers/iommu/iommu-debugfs.c that also has this message:

    If you see this message and you are not debugging the kernel,
report this immediately to your vendor!

That way this is unlikely to be enabled in distro kernels.

Brian

Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

[Roberto A. Foglietta]

On Fri, 17 Apr 2026 at 21:24, Brian Masney <bmasney@redhat.com> wrote:
>
...
>
>     If you see this message and you are not debugging the kernel,
> report this immediately to your vendor!

Brian, busybox is taken. The escalation up to the vendors is nil.

When people playing cards meets people playing chess... (sergio leone
background track music)

Best R-