The message in the subject shows up many times during a high priority (97) thraed run. I am trying to understand how interruptions affect performence when the application misses a deadline. I couldn't find in the trace what the OS scheduled in place of the applications thread.
For example, the thread runs for ~4ms and was interrupted more than 1000 times.
During an "interruption", the CPU is running an "interrupt handler". There isn't any additional context available, but typically interrupts are related to hardware events, such as timers firing, an IPI (inter-processor interrupt), flow control, or drivers that need the CPU to react to incoming data. Interrupts are the highest priority and will preempt anything running when they fire, so the OS and drivers try to spend as little time as possible in the handler. So, generally speaking, if the interrupt handlers are causing the application to miss deadlines, the deadlines are probably too tight to be feasible, or the device is handling an overwhelming amount of I/O.
I saw the WWDC video about Metal Game Performance and set the phtread priority to 45 as it was shown in the session. My thread routine creates a MTLCommandBuffer und encodes compute and render commands into it. There is not much other CPU work beside filling the MTLCommandBuffer.
By using instruments I can observe two interrupts in each renderloop ("Interrupted for # while CPU # serviced an interrupt handler").
First I thought these two interrupts could be because I had two callback handlers for the command buffer in my code. But this was not the cause for the thread interruptions.
@cwoolf As you said the interrupts have less impact to the app performance (a few mikroseconds/nanoseconds). But is there an way to find out what the reasons for these interrupts are? For my application I would say the reason can be in the Metal commands I have in my code. Even there are no buffer callbacks maybe there are internally some syncronization task between the CPU and GPU that cause the interrupts. I will examine this further. But what I cannot understand why the interrupts are not at the same time position even the command buffers render/compute the same content. Is it possible to run threads running metal code without any interrupts?
The interrupts are not directly related to your code. They are from hardware, typically. Even though your thread has its priority set very high, there are still some housekeeping tasks that the OS must perform at an even higher priority.
So, for example, on a Mac there will be interrupts from moving the mouse, pressing or releasing keys on the keyboard, etc. Given that you're doing GPU work, there are probably interrupts from the GPU. But there's nothing your app can do to avoid those.
Hi Ken,
thanks for your response. Correct me if I am wrong but aren't interrupts related to UI events only affecting the core zero and no other cpu cores? With the GPU I see this also. There really seems to be interrupts where we can't do anything about. I will strip now the metal calls in my application to see if the two interrupts are related to some special Metal methods. If so then I can be sure that there will be no more interrupts in each thread loop. Some mikroseconds are still ok for my application.
Sometimes drivers are architecturally bound to certain core numbers, but usually this is not the case and thus there is no rule of thumb when determining what interrupts go on which core. Also note that the Game Performance template in Instruments includes a Time Profiler, and the time profiler will fire interrupts on all cores once per millisecond. You could also be seeing interrupts which are side effects of the profiling. You can actually see this because the interrupt will overlap with a sample in Time Profiler.
