From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04B573D47A5 for ; Mon, 30 Mar 2026 13:38:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774877907; cv=none; b=lXIs+GjTLOd1j04yQd7r074gRQsHEnLode/IQsDFdQj+F1tea/WEoKSk7z5ZIuA2F75PHt2ZoRGwBK73Vr9LbQraMfVDtUlk4aZm31ZQalRVs+Tt5JPHOMzMAYV9cS+6nvTtaQgqyH+ocfkL8p38RaZA7pLFyVTtdp9gQxMHXeo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774877907; c=relaxed/simple; bh=RrqPwUTqEGSLs/qe8j7V9519WR0mB2p6TiOM/sI99YI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RxWa8WBPyoZGbpxZHBkeWiEtRF7Xhzp7FgKaw6eGAhmj+0BwKK6sFTDcyFL/NWUws2uv2uGciPcgIAit2jvTlXW2ipTDntoyfDfDyflW+f4MqQjAbU2tjlIHDYMnm74et35e0sBLlmtXFscPfbJyliHJwZe8OAe/En8/mbS2PDU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pA3iVf4a; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pA3iVf4a" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-48700b1ba53so40110255e9.1 for ; Mon, 30 Mar 2026 06:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774877904; x=1775482704; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=1K6y9UsF1LewekM6lbBYNrYJF23PRCqYpwk55A2eahA=; b=pA3iVf4at0n1Dk+uCuV0jywyOz8zydHO5R+WDOoxWu7iYnP9sf7Km9D2Y1AW054ruT QTt9f+KSObhvgPiBTK5JYhRzvVxE8Me1DOkAITgtScc2xB39tUMMUXDaH+HiUCw8JuJF hTgvzbnkMkUbDTwtLACwmKxaDuA+RJo25Xu3rTc3wq7Mj70x0vEjYaOIOmBbN5Eb7OqU IZR1V0Mi0HrJbqnTjmm9f8jxOxnzC+sykXUzw5a3TE/QegKH3tFk1vEdCrQ6D14jvMSg fni65n7PJR/bO+j1mIH4eVeKxHJ4C7xjBx7wQGJ2ItiVbKZzEpCYpIv6lmmcQ13iAZeW 1kdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774877904; x=1775482704; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1K6y9UsF1LewekM6lbBYNrYJF23PRCqYpwk55A2eahA=; b=LDZslu26U3z6/zGuaEjdA/2QaoWyNgZjBL55OVczh9rHaQbfdonM2Rm4LS+v2henNd XFGg5skp5d70/ZWxErEyuKiyh65DJDwTk0+ujbBfURlnBuee6/OqMTX3KEF8Mt3V+CWl 9QjG7kwYbraqqnoO6Hmlr4S/PiRdj9bU5TTBOdvQlvbkmVPX8raD6g0Cf3dXiJLtCRdf 8lT0gUV76oRkHmvZ92HNWnnZjKT1KNMm3Z/vdftEbbnTu2uhjg7+OA61vy6NZk8flwEg LUWf2c5YZvboq96yO6GQNjLKaHaYgCi6B3jJiNoOV2VeBF4JxegDouE46LHO8S4jTXO/ xfaw== X-Forwarded-Encrypted: i=1; AJvYcCW4OhdE+E1W174Y7xqZpJIO//K/H+pH5EwlZuq+8vIA+17k2CgaMnMWRIYV/Io8OsTjjfmSpKCkrz40XFk=@vger.kernel.org X-Gm-Message-State: AOJu0YxtKej5D6yGfI/r58vDg9I+1pIbPHnj19OGzlSxHW7xUX/lHlMQ l5xiQ2vsPQyZh+yMVdUIx354RNJs72nDKs2hVBL5/dOYw3LnnIAUi+Lu X-Gm-Gg: ATEYQzwHq7LzlQMUzYnSNd7Z1atHqg3Rty8l6CLWpiRxsoqX5veBR0x7bh8NxmPAK1a CzwmdWSVIXXk/tIycwhtkUpy9meu3Kl2UYHMicVIa7CfgIwO496fLnM1IVhmCSER59XxqCklrn8 qd04wuEafnqU6VPx4uVD5asdbdG3nn+r10rs42lUMtVsNGw0SoSydMgvtfGHa1XzISrlHPY3Sof kNLDcejC9JQvchFn+9IcMhwA9HDxK6KBW0O5xZGriinJkRUbmRuVWr9s+BVA7Pcub6Wqp4FrGtT 7gMvq1B9ZKwBgD2/U/QwN0ox5mBUXN+uyS+/sXmB1fLEmlecfEr51sdG12s1CEqWsCROchYFj7L r7nngIf3G4Snj9GyqehUnTSeN9VJoMBKrqOatGAoSv2QbiM6ihDiRYwwCBMqPzMsDN52tYTLFnJ N9Uou2nwG1PL+tM0ypjGY25TNw2U6gWIhMrP+zoyLDlllUSLLDTjUBzBVEq5KI X-Received: by 2002:a05:600c:5249:b0:487:386:3714 with SMTP id 5b1f17b1804b1-48727f7bb08mr231528425e9.17.1774877904186; Mon, 30 Mar 2026 06:38:24 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48722d40741sm294000475e9.13.2026.03.30.06.38.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 06:38:23 -0700 (PDT) Date: Mon, 30 Mar 2026 14:38:20 +0100 From: David Laight To: Thomas Gleixner Cc: "Bird, Tim" , "pmladek@suse.com" , "rostedt@goodmis.org" , "senozhatsky@chromium.org" , Shashank Balaji , "john.ogness@linutronix.de" , "francesco@valla.it" , "geert@linux-m68k.org" , "linux-embedded@vger.kernel.org" , "linux-kernel@vger.kernel.org" , x86@kernel.org, Paolo Bonzini , Sean Christopherson , KVM Subject: Re: [PATCH v3] printk: fix zero-valued printk timestamps in early boot Message-ID: <20260330143820.605b29ed@pumpkin> In-Reply-To: <87fr5ib6ks.ffs@tglx> References: <39b09edb-8998-4ebd-a564-7d594434a981@bird.org> <20260210234741.3262320-1-tim.bird@sony.com> <87zf3ud92r.ffs@tglx> <87jyuvboo2.ffs@tglx> <87fr5ib6ks.ffs@tglx> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 30 Mar 2026 00:42:59 +0200 Thomas Gleixner wrote: ... > If you want to have early timestamps then you have to go through the low > level code on every architecture and do the proper sanity checks, > enumerations, etc. no matter what. There is no guarantee that you can > use any clock unconditionally during very early boot. > > As you have to do that anyway, there is _zero_ justification for an > extra facility side stepping sched clock, which would just create > another pile of technical debt. > > Quite the contrary, I'm going to get rid of technical debt: > > The get_cycles() related changes in tsc.h are going to end up in a > obviously revised formal patch tomorrow as there is exactly _zero_ > requirement to provide this as a functional interface. > > 1) The default implementation in asm-generic returns 0 > > Ergo any code depending on a functional implementation is broken > by definition. > > 2) The ops/cycles metrics are as bogus as the infamous BogoMIPS metrics > > The "cycle" counter runs on almost all contemporary CPUs at a fixed > frequency, which is completely unrelated to the actual CPU > frequency and therefore to the actual CPU cycles. > > The only realistic metric is ops/sec and nothing else and that can > be trivially achieved by using the generic time getter interfaces. ops/sec is also horrid because you get all all the interrupt time getting in the way. Additionally it is only any use for relative comparisons done on exactly the same hardware, and is entirely useless is you are trying to show that a short code loop is running at/near the theoretical rate. The only thing I've found that works is the PERF_COUNT_HW_CPU_CYCLES counter (low 32 bits). In userspace you do have to directly read the register (rather than using the library function - too much overhead), and ignore any silly values generated by interrupts and process switches. But it is accurate enough to time single function calls and see the effect of things like mispredicted branches and the data-dependency of divide instructions. But I do agree that the TSC is entirely useless for measuring what it was originally intended to measure. David > > Those might end up resulting in bogus benchmark results too if the > underlying clocksource is jiffies, but that's again a matter of > accepting reality. > > If people really mandate that ops/bogo_cycles is required for the > very wrong reasons, then I'm happy to bring it back with a global > name change from get_cycles() to get_bogo_cycles() which excludes > it from any serious usage including printk. > > Thanks, > > tglx