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 4CF4F3FA5E4 for ; Mon, 7 Sep 2026 09:37:05 +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=1788773827; cv=none; b=Wx7sPle+dB3hRreyZtPWuRUGsGCz7AeeG8wz8uh+gqWwzSH8x4PEW3X4PYGB+JSvDeq3EBOHb29UspSeGTtpA0kyePGKanLOqG6gvcNc4Z7AhnO9KISyVwCoOJA83er/OsEnueQs6VduxJ8745PgoLClHIVA7nkBvO/FpVme7L8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788773827; c=relaxed/simple; bh=j/rI21C7UgFZDa/CclhUY0KnOJAP3P6Y6f5aZiFVqaA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ANzyutlH1X7K8t3ghKxFNtpywioWbTtrFM8cnHPN5RNm8jcEvtEqvcTETFoLYZAw6hvYyNnMe9UoAxokb1L9/3eB/tspDnNfyBxxOigaotgFryPjadYXHzOEZqN8DwnKGEDf4BMyuAq93vJt7CvpOa9lTaF+KwNQqt57/sR0GNc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LuYm8KGS; 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="LuYm8KGS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C378F1F00A3A; Mon, 7 Sep 2026 09:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788773825; bh=DhzeFuohvVP4p4JxIz/rcrKXCteQ76uy4LkvjDALHC8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LuYm8KGSqwwahc1MurXVVJJ9Vzn5SC8KWYgNLVf2YJue3uIHQkqnmbGt8opcV+8ef Pm0V075u3KO9y1VIq2VRZLAmBABAZTVsVEbsT2CVWcBhzf2Wo5814FHwPJJHRCLGfI +ciSa/X0OeNvyoObGfFIdDb3XMckthoznjlkvA62ih2fHQ4ScSxrG0xz2hqvsemdwJ C/LD8S/X6fDIy8rsb5/OOlzbwN/ODJl+ne0NNUgaod+LCHSnZrJmSFtLsB2GpY9r9y VvVqenxbQzFp3skX94dAkT0z3CF8duOj5vOQRL/y0wUy+ineTGcFt2p7zWHOJwc4MS ofvcuQY5mXuzA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1x3Vmh-00000005gGv-2SII; Mon, 07 Sep 2026 09:37:03 +0000 Date: Mon, 07 Sep 2026 10:37:03 +0100 Message-ID: <86h5k14d34.wl-maz@kernel.org> From: Marc Zyngier To: Feng Tang Cc: 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> <8733vn5t6p.ffs@fw13> 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: 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 Mon, 07 Sep 2026 10:05:40 +0100, Feng Tang wrote: > > On Sat, Sep 05, 2026 at 10:39:26PM +0200, Thomas Gleixner wrote: > > On Wed, Sep 02 2026 at 16:21, Feng Tang wrote: > > > 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 told you before that we don't care about your bug chasing war stories > > at all. Educate your firmware people and stop pestering us with your > > firmware debug hacks. > > Hi Thomas, > > Yes, this patch is hacky. > > From the reply of Marc in this thread: > > " > 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. > " > > IIUC, getting an absolute timestamp for logs is still practical in some > cases. How about adding the offset-since-reset info into the message > like Marc suggested: > > --- > diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c > index f3aaef695b8c..d5a54276b49d 100644 > --- a/kernel/time/sched_clock.c > +++ b/kernel/time/sched_clock.c > @@ -176,7 +176,7 @@ static enum hrtimer_restart sched_clock_poll(struct hrtimer *hrt) > > void sched_clock_register(u64 (*read)(void), int bits, unsigned long rate) > { > - u64 res, wrap, new_mask, new_epoch, cyc, ns; > + u64 res, wrap, new_mask, new_epoch, cyc, ns, reset_ns; > u32 new_mult, new_shift; > unsigned long r, flags; > char r_unit; > @@ -235,8 +235,11 @@ void sched_clock_register(u64 (*read)(void), int bits, unsigned long rate) > /* Calculate the ns resolution of this counter */ > res = cyc_to_ns(1ULL, new_mult, new_shift); > > - pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n", > - bits, r, r_unit, res, wrap); > + /* Calculate the time since last counter resetting to 0 */ > + reset_ns = mul_u64_u64_div_u64(new_epoch, NSEC_PER_SEC, rate); > + > + pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns, has run %lluns since counter reset\n", > + bits, r, r_unit, res, wrap, reset_ns); > > /* Enable IRQ time accounting if we have a fast enough sched_clock() */ > if (irqtime > 0 || (irqtime == -1 && rate >= 1000000)) > Which is what people have done locally since the beginning of times. And the only time this is actually useful is when bringing up new HW/FW that is broken. So why the need to put that in an upstream kernel, instead of being as part of your debug toolbox? I don't think the kernel shouldn't be the recipient of this sort of stuff. M. -- Without deviation from the norm, progress is not possible.