On Mon, Aug 10, 2020 at 08:25:03PM +0000, Frank van der Linden wrote: > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > commit f0c7baca180046824e07fc5f1326e83a8fd150c7 upstream. > > John reported that on a RK3288 system the perf per CPU interrupts are all > affine to CPU0 and provided the analysis: > > "It looks like what happens is that because the interrupts are not per-CPU > in the hardware, armpmu_request_irq() calls irq_force_affinity() while > the interrupt is deactivated and then request_irq() with IRQF_PERCPU | > IRQF_NOBALANCING. > > Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls > irq_setup_affinity() which returns early because IRQF_PERCPU and > IRQF_NOBALANCING are set, leaving the interrupt on its original CPU." > > This was broken by the recent commit which blocked interrupt affinity > setting in hardware before activation of the interrupt. While this works in > general, it does not work for this particular case. As contrary to the > initial analysis not all interrupt chip drivers implement an activate > callback, the safe cure is to make the deferred interrupt affinity setting > at activation time opt-in. > > Implement the necessary core logic and make the two irqchip implementations > for which this is required opt-in. In hindsight this would have been the > right thing to do, but ... I backported this one since it had a minor conflict, so while the main one was Cc-ed to stable@, it didn't get picked up. Ran it through all our regression tests and the reproducer case, and it's fine. - Frank
