Re: [PATCH] sched/psi: clamp negative cpu_clock() skew

[David Stevens]

On Wed, Sep 30, 2026 at 8:19 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Wed, Sep 30, 2026 at 10:22:52AM -0400, Johannes Weiner wrote:
> > On Tue, Sep 29, 2026 at 10:17:40AM +0200, Peter Zijlstra wrote:
> > > On Tue, Sep 29, 2026 at 10:10:04AM +0200, Peter Zijlstra wrote:
> > >
> > > > > When running browser workloads on an Intel N100 with a sustained
> > > > > psi.mem.some of 2-3%, this underflow is observed once every couple of
> > > > > hours.
> > >
> > > Reading is hard. This is sad, that's a relatively modern chip :-(
> >
> > I'm still struggling, but I'm under the weather so bear with me.
> >
> > That's a cpu_clock() implementation issue, right? "The value for
> > cpu_clock(i) is monotonic for constant i". Presumably violating that
> > would be a problem beyond psi?
>
> Yeah, although most everybody has a filter on top for some reason or
> another.
>
> Mostly it could happen that when the watchdog would detect the TSC
> wasn't stable after all, you'd be up a creek if you didn't also have
> this filter.
>
> But I'm very sad to see modern chips have shit TSC, that wasn't supposed
> to happen.

I ran artificial memory pressure tests on the other two devices I have
at hand - one with an Intel i5-1245U and one with an Intel Ultra 5
325. Both devices also observed negative elapsed durations. The
artificial workloads were much heavier and actually produced negative
elapsed durations every couple of minutes. So this doesn't look like a
platform-specific issue.

For reference, the negative elapsed durations I saw averaged a little
under 100ns. The largest duration I saw was 371ns.

If I'm following the code correctly, cpu_clock() on x86 ends up
calling rdtsc() via sched_clock(). The rdtsc() function is documented
to produce non-monotonic results when compared across CPUs, since the
rdtsc instruction can read the tsc out of order relative to other
instructions. If that results in get_recent_times() reading the tsc
before it reads the psi state, then I think that would explain the
negative skew. I added a rbm() immediately before the call to
cpu_clock() in get_recent_times() to match the behavior of
rdtsc_ordered(), and with that I didn't see any negative elapsed
durations during overnight testing. This does suggest that calling
through to sched_clock() might not provide strong enough guarantees on
x86 to satisfy the cpu_clock() contract.

-David