On Mon, Mar 26, 2012 at 09:04:20PM +0200, Thomas Gleixner wrote: > On Mon, 26 Mar 2012, Yevgeny Petrilin wrote: > > > > > > > The architecture specific code will determine whether the IRQ could be migrated > > > in process context. For example, the IRQ_MOVE_PCNTXT flag will be set on x86 > > > systems if interrupt remapping is enabled. > > > > Actually I am encountering this issue with x86, and see different > > behavior with different HW devices (NICs). On same machine I have > > one device that responds immediately to affinity changes while the > > other one changes the affinity only after first interrupt. > > That simply depends on the underlying hardware. On certain hardware we > can change the affinity only in hard interrupt context, that means > right when a interrupt of that device is delivered. > > On the other devices we can change it right away and the corresponding > interrupt chips set IRQ_MOVE_PCNTXT to indicate that. Actually, even with IRQ_MOVE_PCNTXT capable chips, a hardware handler still might be called on a core that belongs to old affinity, after the successful write of new affinity. Threaded handlers are also racy with irq affinity updates. If that is inconsistency, bug or design? > There is nothing we can do about this. It's dictated by hardware. May be we could wait for desc->pending_mask to be cleared before returning from irq_set_affinity()? > Thanks, > > tglx > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Regards, Alexander Gordeev agordeev@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
