Hi Sebastian,
On 17.06.25 11:28, Sebastian Andrzej Siewior wrote:
Between those two functions you have 800us delay. Interrupts are not
disabled so the CPU stalls. As explained earlier, I expect the read on
the bus flushes the writes causing the spike.
So the delay you think is really the hardware(CPU) being stalled on the
bus for so long? Or do you mean that this is the reason for the long
runtime of the IGB function only?
Shouldn't the other core (it is 2 core machine) still be able to handle
the timer interrupt then? (I did some testing with isolating IP on one
core and cyclictest on the other, I am not sure if I moved the timer IRQ
to the second core)
My mistake was to search for where the Interrupt was being disabled in
Kernelspace (I did not think that the hardware could introduce and IRQ
delay for 800us..)
Marc
