On Tue, 27 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. > > > > There is nothing we can do about this. It's dictated by hardware. > > > > Thanks for the explanation, > Which capabilities of the HW show whether IRQ_MOVE_PCNTXT can be set or not? > Is it done by reading configuration from PCI? It's done by reading the specs of the interrupt controllers. This is not at PCI (device) level. It's a property of the interrupt controller (PIC, APIC, IOAPIC) and additional features like interrupt remapping. The device merily uses an interrupt, but it does not know at all which underlying interrupt controller is handling it. The only choice a device driver has is between pin based interrupts and Message Signaled Interrupts, when the hardware supports it. This information is retrieved from the PCI config space. Thanks, tglx -- 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
