[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95da1e97-bcfb-4a47-affc-fcec6e729d5b@amd.com>
Date: Tue, 27 Jan 2026 09:08:32 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Wangyang Guo <wangyang.guo@...el.com>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann
<dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall
<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
<vschneid@...hat.com>
CC: <linux-kernel@...r.kernel.org>, Shrikanth Hegde <sshegde@...ux.ibm.com>,
Benjamin Lei <benjamin.lei@...el.com>, Tim Chen <tim.c.chen@...ux.intel.com>,
Tianyou Li <tianyou.li@...el.com>
Subject: Re: [PATCH v5] sched/clock: Avoid false sharing for
sched_clock_irqtime
Hello Wangyang,
On 1/27/2026 8:46 AM, Wangyang Guo wrote:
> @@ -238,6 +239,8 @@ static int __init sched_clock_init_late(void)
>
> if (__sched_clock_stable_early)
> __set_sched_clock_stable();
> + else
> + disable_sched_clock_irqtime(); /* disable if clock unstable. */
nit. I think we should check for irqtime_enabled() before since
static_key_disable() would grab the cpus_read_lock() unnecessarily even
if irqtime wasn't enabled - possible with PA-RISC where a slow processor
registers the generic sched clock not eabling irqtime and then marks the
sched_clock unstable on SMP which would hit this without having irqtime
enabled.
Same is case with "tsc=noirqtime" and then tsc turns unstable at early
boot.
--
Thanks and Regards,
Prateek
Powered by blists - more mailing lists