From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81B764334AD for ; Thu, 3 Sep 2026 07:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788420987; cv=none; b=fOEi3h4cU3NBAhCmY99ZdvF2p4jXKlH/ka+ICiOxiGRLB6LjgZzhQh11VhnsKXxPQ9dOQmUi5lCGuwrprjd+u7CSYoKCedaRhj090pAj1uKtSTqAADCPX5D3/Ce+qaD6CKT4ODYby6ffZu20CoG8NHq+occ91tmcS8MEABPiqhE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788420987; c=relaxed/simple; bh=Aii2dVuPvBApXPQfvnroOB8Iu8zKlFukUJulXOZfnvM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=lBY7wbPIKND/KbaLHKv78upRaeK/xQbOGKYFdp0k7WfpMvDibhufJGjt0UY+vHc/i4DP0yjtNTJc1f2iVCbJXSYqEACLGO1TGqrknHEkXC/94Ef7v950MgE7x1vxfwouLGoevLYEIMF7QcR0a7xPQHx1MJQo5aXVNbzBuQLq81A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iEcuTLoG; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iEcuTLoG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FB4C1F000E9; Thu, 3 Sep 2026 07:36:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788420986; bh=v3Y0pF6qaEUidBIul6qJ8AoENef+pkWSii7H+USK2Xw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=iEcuTLoG5eyYSRVRMKPZDL4De+trkH8sGOxaZG+sxaDCAHFp9LVl0/36eZMo2RrDi RmYQuenIFi0Zew+rim0i4aqZ90qvDkJc19IbVUTyUeP7EJNkiUnYu2M0SxWlOFRMlU KslqrExVumKUkLPScCy5fhe9sETmBETxMbCvDvQuwmE1fmYqJ9dLCKkD89DX3sGUHE Up31+Rg8eUNgK0m0Jf5vbSSJNpcIWUVW1qxoknhNqJxvR59x28TmUME1dnG7SoCMma CM78HPRCgraCRqaS2DzNr/vW2v0H54F6Gy9twvDk2aaUbPEw4okfG1/8YaKS3LsX45 rcEc+grfobqog== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x21zj-00000004Ekw-3455; Thu, 03 Sep 2026 07:36:23 +0000 Date: Thu, 03 Sep 2026 08:38:57 +0100 Message-ID: <878q5i6ay6.wl-maz@kernel.org> From: Marc Zyngier To: Yao Yuan Cc: Feng Tang , Thomas Gleixner , John Stultz , Stephen Boyd , Miroslav Lichvar , Daniel Lezcano , Peter Zijlstra , Petr Mladek , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched_clock: Add option to use absolute time against hardware clock reset In-Reply-To: References: <20260902082123.95770-1-feng.tang@linux.alibaba.com> <87h5k7mzxy.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: yaoyuan@linux.alibaba.com, feng.tang@linux.alibaba.com, tglx@kernel.org, jstultz@google.com, sboyd@kernel.org, mlichvar@redhat.com, daniel.lezcano@kernel.org, peterz@infradead.org, pmladek@suse.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 03 Sep 2026 07:51:03 +0100, Yao Yuan wrote: > > On Wed, Sep 02, 2026 at 04:32:25PM +0800, Marc Zyngier wrote: > > On Wed, 02 Sep 2026 09:21:23 +0100, > > Feng Tang wrote: > > > > > > Currently sched_clock shows the relative time to the boot starting of > > > kernel, while there could be long firmware start time before it and > > > after the hardware reset. > > > > > > On modern server platforms, there could be several software running in > > > parallel. Like for arm64, it could have SCP (System Control Processor) > > > firmware running on SCP processor, and ATF (Arm Trusted Firmware) and > > > Linux OS on the main processor. > > > > > > Debugging some nasty issues on these platform may need to cross-check > > > the logs from these firmwares and Linux kernel for specific events, > > > where a unified reference timeline is critical. All these software can > > > read the hardware timer, which is also the base of sched_clock for > > > Linux kernel. Using the absolute counter since hardware timer reset > > > makes it possible for all kinds of software to have a same time base. > > > > > > Add 'abs_sched_clock' parameter to provide an option for using absolute > > > counter, and users should make sure their sched_clock (hardware timer) > > > is capable of supporting absolute counter before enabling the option. > > > > > > Locally, it did help on chasing some RAS issues which needed cooperation > > > between kernel, SCP firmware and ATF, by mapping the actions from each > > > players into one timeline based on the timestamps in their logs. > > > > I really have to ask: why isn't this just a one-off sampling of the > > counter, kept in some user accessible location (debugfs or something > > else), and ultimately post-processed to align your logs? People have > > been doing this... forever, and that has been "good enough" so far. > > > > Hi Marc, > > > The other thing is that your "absolute" clock isn't absolute at > > all. This doesn't consider SW running at EL2 that could happily offset > > thing by an arbitrary value. > > Do you mean the VM case that VM's vcounter can be changed by hypervisor > in EL2, Thus it's not that absolute in such scenario ? That's indeed one of the possibilities. EL2 controls both virtual and physical offsets, and therefore provides the kernel with a different view of time. This doesn't even have to be a VM. There is a lot of non-hypervisor SW out there that just hogs EL2 for more or less nefarious purposes (such as "protecting" the kernel), and offsetting the counter values is one of thing they could do to hide what they are doing. The other thing is that this change seems to break the sched_clock() handover, since the new clock doesn't start where the old one ends. This doesn't affect arm64, which can only have one true source of time, but other archs would probably suffer from this. M. -- Jazz isn't dead. It just smells funny.