On Fri, Mar 07 2025 at 19:10, Tsai Sung-Fu wrote: > Thanks for your detailed explanation and feedback, I am a bit confused about the > #4 you mentioned here -> > >> 4) Affinity of the demultiplex interrupt > > Are you saying there is a chance to queue this demultiplexing IRQ event > to the current running CPU ? The demultiplexing interrupt (currently a chained handler, which is hidden from /proc/irq/) stays at the affinity which the kernel decided to assign to it at startup. That means it can't be steered to a particual CPU and nobody knows to which CPU it is affine. You can only guess it from /proc/interrupts by observing where the associated demultiplex interrupts are affine to. So ideally you want to be able to affine the demultiplexing interrupt too. That requires to switch it to a regular interrupt for simplicity. We could expose those hidden chained handlers affinity too, but that needs some surgery vs. locking etc. > And that's really an approach worth to try, I will work on it. I've played with this on top of variant of Marc's changes to use MSI parent interrupts for such controllers too: https://lore.kernel.org/all/20241204124549.607054-1-maz@xxxxxxxxxx/ A completely untested and largely uncompiled preview is here: https://tglx.de/~tglx/patches.tar The MSI parent parts are in flux. Marc will look at them in the next weeks, but I picked them up because it simplifies the whole business a lot. If you find bugs in that series, you can keep them :) Thanks, tglx
