linux-kernel - Re: [PATCH v3] sched/clock: Avoid false sharing for sched_clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKfTPtDc=aiXXYZKx3wQzV70=KbK0DKSOQLqHjMT+CPrTmdm_g@mail.gmail.com>
Date: Fri, 23 Jan 2026 16:58:11 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: Wangyang Guo <wangyang.guo@...el.com>, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>, 
	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>, 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 v3] sched/clock: Avoid false sharing for sched_clock_irqtime

On Fri, 23 Jan 2026 at 05:51, K Prateek Nayak <kprateek.nayak@....com> wrote:
>
> Hello Vincent,
>
> On 1/22/2026 4:06 PM, Vincent Guittot wrote:
> >>> or  unstable clock need another workqueue for disabling sched_clock_irqtime
> >>
> >> Ack! We'll likely need a second workqueue and call it early in
> >> __clear_sched_clock_stable().
> >>
> >> AFAICT, PA-RISC already suffers from this since it marks
> >> sched_clock_unstable() on SMP but since it uses the generic sched_clock,
> >> on a >= 1MHz processor, it enabled irqtime anyways and nothing disables
> >> it later (unlike TSC, the clocksource doesn't have a "mark_unstable"
> >> callback).
> >
> >>
> >> If we can delay enabling the irqtime accounting until we do
> >> __set_sched_clock_stable() for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK (I have
> >> no clue if this is acceptable of not), then we can move the enabling /
> >> disabling of irqtime to the same spots as when we flip
> >> __sched_clock_stable.
> >
> > Do you mean to delay the enabling/disabling of irqtime accounting in
> > sched_clock_init_late for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK case ?
>
> Yup!
>
> >
> > I don't have system with unstable clock so I'm not the best to answer
> > but if irqtime accounting is not compatible with unstable clock it
> > should be enabled at the same time as the clock is marked stable
>
> Here are logs from my system with stable TSC highlighting the flow:
>
>     [    0.000000] tsc: Fast TSC calibration using PIT
>     [    0.000000] tsc: Detected 1996.299 MHz processor
>
>     # native_sched_clock() stats using TSC from jiffies
>     # Once we hit sched_clock_init() we'll start using
>     # local_clock_noinstr which uses tsc.
>
>     [    6.497022] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x398d0c7513b, max_idle_ns: 881590744042 ns
>     [    6.507546] Calibrating delay loop (skipped), value calculated using timer frequency.. 3992.59 BogoMIPS (lpj=7985196)
>
>     # tsc-early is registered
>
>     [   10.455611] clocksource: Switched to clocksource tsc-early
>
>     # Clocksource has switched to tsc-early
>
>     [   13.863291] tsc: Refined TSC clocksource calibration: 1996.250 MHz
>     [   13.869689] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x398caf77d7a, max_idle_ns: 881590459467 ns
>     [   13.880722] clocksource: Switched to clocksource tsc
>
>     # Full tsc switch now that HPET is registered and the granularity
>     # of TSC calibration can be found more precisely
>
>     [   15.382498] sched_clock: Marking stable (15304347096, 75265818)->(17063112601, -1683499687)
>
>     # sched-clock is finally marked stable at sched_clock_init_late()
>     # __sched_clock_offset is calculated and __sched_clock_stable is flipped
>
>
> If TSC / any potentially unstable clock is marked unstable before
> sched_clock_init_late(), we never flip __sched_clock_stable.
>
> On x86 side, since we already start using TSC for native_sched_clock()
> super early, we have defensive measures (and a __use_tsc static key on
> the x86 side too) to switch the sched clock back to jiffies if we
> realise TSC was unstable before we hit sched_clock_init_late().
>
> This is necessary since post the sched_clock_init(),
> "sched_clock_running" is true and the local clocks will always uses
> sched_clock_noinstr() and it must be switch to jiffies on the x86 side
> since arch defines it.

sched_clock_init_late() is always called so can't we check if
irqtime_enabled and clock is unstable then we disable irqtime
accounting

>
> --
> Thanks and Regards,
> Prateek
>