> 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.htm...
> 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.
pkhuong in this comment: http://disq.us/p/271zzg1, suggests that he's using an Intel CPU. As such...
> For example, page 18/37 of Intel's manual volume 3B (https://www.intel.com/conte... states that when an instruction causes a PEBS assist, the PEBS record will point to the next instruction: "The return instruction pointer (RIP) reported in the PEBS record will point to the instruction after (+1) the instruction that causes the PEBS assist. The machine state reported in the PEBS record is the machine state after the instruction that causes the PEBS assist is retired."
Since PEBS is activated, we can be assured that the instruction samples are just one instruction away from the triggering instruction.
--------
The discussion includes a link to this blog post that further discusses this "skid" problem: http://sandsoftwaresound.net/perf/perf-tutorial-hot-spots/
> The combination of these two factors is called skid and it affects the attribution and distribution of samples in the final profile. In the presence of skid, samples are attributed to the general neighborhood around performance culprits such as long latency memory load operations. The cpu-clock event cannot be precisely attributed to slow instructions — just the hot code region containing the culprit.
Its important to know if you're running an AMD or Intel CPU! The hardware performance counters are implemented differently between the manufacturers! So this low-level profiling information should always have the CPU-type close by, for clarity.