> Hmm, in my experience with AMD-based hardware profiling, AMD CPUs may place the blame as far back as ~200 instructions (pathological worst-case) behind the in

> Hmm, in my experience with AMD-based hardware profiling, AMD CPUs may place the blame as far back as ~200 instructions (pathological worst-case) behind the instruction that was interrupted. > Since PEBS is activated, we can be assured that the instruction samples are just one instruction away from the triggering instruction. I don't think PEBS is activated here (techncially, it's AMD so there is no PEBS, but let's talk about IBS or whatever the AMD equivalent is) - Paul never mentions PEBS except when quoting an Intel manual and in any case PEBS (or AMD equivalent) should put it on the right instruction, not the next one. What's going on there is that when you want to sample "time" or any closely related thing like "cycles", the concept of skid doesn't really apply. Skid applies mostly when some other type of event is tracked by the PMU, and then interrupt occurs and it might take many cycles for the interrupt to occur. With time though, that doesn't really matter. Sure the Linux timer fires (e.g., for task-clock based sampling) or the PMU fires (e.g., for cycles-based sampling), and then some time later the interrupt takes effect, _but this later point is also a totally valid sampling point and tends to interrupt slow instructions (or "one after" slow instructions). That is, if you are sampling every 10,000, your samples are just as good if they occur at 10,035 us or whatever, rather than 10,000: in the case that you care about sampling instructions. This reasoning doesn't apply for other types of events, where the place the process is interrupted isn't "just as good" as the place the event fired, because the event isn't instruction/time based. So for instruction/time sampling, PEBS doesn't provide much benefit, except by removing the 1-instruction skid ("skid" is not really the right word, IMO, it's just a consequence of the fact that CPUs generally only raise interrupts at the end of the instruction, so slow instructions complete and the next instruction is indicated). More details at [1]. [1] https://travisdowns.github.io/blog/2019/08/20/interrupts.html https://travisdowns.github.io/blog/2019/08/20/interrupts.htm...