Re: [PATCH v3] sched/clock: Avoid false sharing for sched_clock_irqtime

[K Prateek Nayak <kprateek.nayak@amd.com>]

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.

-- 
Thanks and Regards,
Prateek