The term “interrupt affinity” refers to the binding of interrupts from a specific device to one or more specific logical processors in a multiprocessor server. The binding forces interrupt processing to run on a specified logical processor or processors, unless the device specifies otherwise during its initialization. For some scenarios, such as a file server, the network connections and file server sessions remain on the same network adapter. In those scenarios, binding interrupts from a network adapter to a logical processor allows for processing incoming packets (SMB requests and data) on a specific set of logical processors, which improves locality and scalability.
You can use the old Interrupt-Affinity Filter tool (IntFiltr) to change the CPU affinity of the interrupt service routine (ISR). The tool runs on most servers that run Windows Server 2008 R2, regardless of what logical processor or interrupt controller is used. For IntFiltr to work on some systems, you must set the MAXPROCSPERCLUSTER=0 boot parameter. However, on some systems with more than eight logical processors or for devices that use MSI or MSI-X, the tool is limited by the Advanced Programmable Interrupt Controller (APIC) protocol. The new Interrupt-Affinity Policy (IntPolicy) tool does not encounter this issue because it sets the CPU affinity through the affinity policy of a device. For more information about the Interrupt-Affinity Policy tool, see “Resources” later in this guide. You can use either tool to direct any device's ISR to a specific processor or to a set of processors (instead of sending interrupts to any of the CPUs in the system). Note that different devices can have different interrupt affinity settings. On some systems, directing the ISR to a processor on a different Non-Uniform Memory Access (NUMA) node can cause performance issues. Also, if an MSI or MSI-X device has multiple interrupt “messages,” each message can be affinitized to a different logical processor or set of processors.
We recommend that you use IntPolicy to bind interrupts only for devices whose driver models do not support affinitization functionality. For devices that support it, you should use the device-specific mechanism for binding interrupts. For example, most modern server NICs support Receive Side Scaling (RSS), which is the recommended method for controlling interrupts. Similarly, modern storage controllers implement multi-message MSI-X and take advantage of NUMA I/O optimization provided by the operating system (Windows Server 2008 and later). Regardless of device functionality, IRQ affinity specified by the operating system is only a suggestion that the device driver can choose to honor or not. IntPolicy has no effect on the synthetic devices within a VM in a Hyper-V server. You cannot use IntPolicy to distribute the synthetic interrupt load of a guest VM.
|
