On Fri, Sep 12, 2025 at 12:15:12AM +0200, Marc Gonzalez wrote: > On 9/11/25 23:29, Marc Gonzalez wrote: > > > - Not sure what the int_misc.recovery_* events measure??? > > They're documented as: > > "This event counts the number of cycles spent waiting for a > > recovery after an event such as a processor nuke, JEClear, assist, > > hle/rtm abort etc." > > and > > "Core cycles the allocator was stalled due to recovery from earlier > > clear event for any thread running on the physical core (e.g. > > misprediction or memory nuke)." > > => In my case, they're probably measuring the same thing. > > Weird that the description sounds a bit different. > > Need to read up on processor nuke, memory nuke, machine clear event, > > JEClear, assist, HLE/RTM... > > Daniel, seems you were spot on when mentioning side channel attacks. I'm sorry if I sounded patronizing, that was not my intent. After we ruled out the OS noise the only thing left was that the runtime variance is from the CPU itself. > https://www.usenix.org/system/files/sec21-ragab.pdf > > I need to truly read & understand this paper. Skimmed over it, it could explain what you are observing. The question obviously is which part of the 'bad' code is confusing the CPU :)
