I asked a question about the PMU skid problem about half years ago (https://community.arm.com/tools/dev-platforms/f/discussions/6986/about-the-interrupt-handling-in-gic), and i understand that the skid exists as the interrupt is an asynchronous exception. However, i found something interesting about the skid, but i cannot explain it.
Assume that we have a list of instruction I1 to I10, and a PMU overflow interrupt is signaled after the instruction I1 is executed. When the interrupt actually fires to the core from GIC, the instruction I10 may be the executing instruction and the instructions I2 to I9 are in the skid shadow. In my understanding, the number of the instruction in the shadow should be almost fixed as the time needed for a interrupt request to be handled in GIC is almost fixed. I tried to use several different PMU event to trigger the overflow, and the result supports my guess.
However, when i tried to use PMU event CPU_CYCLES to trigger the overflow interrupt, things changed. Firstly, the overflow interrupt may be fired several times while executing a single instruction. I understand that the execution of an instruction may last for several CPU cycles, but how could the interrupt arrives to the CPU for several times in the execution of a single instruction? Where is the skid of these interrupts? Secondly, I found that the skid still exist, but the average number of the instruction in the skid shadow reduced. For example, during the execution of the instruction I1, we may receive several interrupts in the interrupt handle. Then, when the next interrupt arrives, the executing instruction is I5. In my test on Juno board, the average number of instruction in the skid is about 18 instructions, but the number suddenly reduced to about 2 instructions when I use the CPU_CYCLES event. This result makes me confused, does anyone know what has happened?
Thanks very much for any help!
View all questions in Arm Development Platforms forum