Re: [PATCH v10 07/14] unwind_user/deferred: Make unwind deferral requests NMI-safe

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Jun 19, 2025 at 05:10:20AM -0400, Steven Rostedt wrote:
> 
> 
> On June 19, 2025 4:48:13 AM EDT, Peter Zijlstra <peterz@infradead.org> wrote:
> >On Thu, Jun 19, 2025 at 10:44:27AM +0200, Peter Zijlstra wrote:
> >
> >> Luckily, x86 dropped support for !CMPXCHG8B right along with !TSC. So on
> >> x86 we good with timestamps, even on 32bit.
> >
> >Well, not entirely true, local_clock() is not guaranteed monotonic. So
> >you might be in for quite a bit of hurt if you rely on that.
> >
> 
> As long as it is monotonic per task. If it is not, then pretty much all tracers that use it are broken.

It is monotonic per CPU. It says so in the comment.

The inter-CPU drift is bounded to a tick or something.

The trade-off is that it can be the same value for the majority if the
that tick.

The way that thing is set up, is that we use GTOD (HPET if your TSC is
buggered) snapshots at ticks, set up a window to the next tick, and fill
out with TSC deltas and a (local) monotonicity filter.

So if TSC is really wild, it can hit that window boundary real quick,
get stuck there until the next tick.

Some of the early had TSC affected by DVFS, so you change CPU speed, TSC
speed changes along with it. We sorta try and compensate for that.

Anyway, welcome to the wonderful world of trying to tell time on x86 :-(


Today, most x86_64 chips made in the last few years will have relatively
sane TSC, but still we get the rare random case it gets marked unstable
(they're becoming few and far between though).

x86 is one of the worst architectures in this regard -- but IIRC there
were a few others out there. Also, virt, lets not talk about virt.