Hi Mark, On Tue, Jun 28, 2016 at 9:59 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Tue, Jun 28, 2016 at 09:39:36AM -0700, Tai Tri Nguyen wrote: >> Hi Mark, >> >> On Tue, Jun 28, 2016 at 7:14 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> > On Tue, Jun 28, 2016 at 02:21:38PM +0100, Marc Zyngier wrote: >> >> On 28/06/16 12:13, Mark Rutland wrote: >> >> > Marc, is there a sensible way to prevent irq balancers from changing the >> >> > affinity of an IRQ, e.g. a kernel-side pinning mechanism, or some way we >> >> > can be notified and reject changes? >> >> >> >> You can get notified (see irq_set_affinity_notifier), but there no way >> >> to veto the change. >> > >> > :( >> > >> >> What should probably be done is to set the affinity hint >> >> (irq_set_affinity_hint), and use the notifier to migrate the context >> >> if possible. Note that you'll be called in process context, which will >> >> race against interrupts being delivered on the new CPU. >> > >> > I'll have to go digging into what exactly perf_pmu_migrate_context >> > requires. Given the race, I'm not sure if that's going to work. It's >> > certainly not going to be self contained. >> > >> > That also won't work for CPU PMUs, where it makes no sense to migrate >> > context or IRQs. For those we appear to already be using have >> > IRQF_NOBALANCING, which sounds like exactly what we want. >> > >> > That appears to influence irq_can_set_affinity(), which the procfs >> > helpers check. >> > >> > Tai, can you try requesting the IRQ with the IRQF_NOBALANCING flag? >> >> This seems to work. >> I also tried to change smp_affinity through procfs and it returns write error. >> The interrupt seems to be excluded from irq balancing. >> Should I make the change? > > Yes please. I believe you also need IRQF_NO_THREAD per the CPU PMU > drivers, so please add both flags. I'll do the same for the CCN and CCI > PMU drivers. Btw, please skip the v5 I've sent out yesterday. I'll soon send the v6 with this change. Thanks, -- Tai -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
