How to Confirm Your Interrupt-Affinity Policy Tool Settings
Setting up your affinities is quite a popular optimization process that can help you reduce your DPC latency and improve the performance of your GPU or the stability of your USB devices. A big issue that I have noticed though is that people do not test if the Interrupt Affinity Policy Tool setting has been saved and is in use or not.
This can lead to placebo settings where the devices remain in their default state leading people to think otherwise.
What Is the Microsoft Interrupt-Affinity Policy Tool?
The Interrupt-Affinity tool is a utility that allows you to bind the interrupts for a device to a specific CPU core. The reason this tool is so useful is because you can effectively dedicate a singular CPU core to an important device in your PC like your GPU, meaning that it will never have to compete with other devices for CPU time.
This leads to better latency since now the GPU has the undivided attention of the CPU core and increased performance for the same reasons. This process makes sense on modern CPUs that have plenty of cores and tasks can be allocated to the lesser-used cores (usually the last couple of cores in your CPU).
This way you also relieve the most popular cores in your CPU (usually the first 3-4 cores) that are heavily used during gaming of some load.
Testing Your Device CPU Affinity
Since you have many devices in your modern PC (can be confirmed by opening your Device Manager) people sometimes fail to bind their actual targets to the designated CPU core leading to no changes in performance.
To test that your affinity has properly been set you can use 2 tools. The first tool which offers a clear confirmation of your device being bound to a different core is LatencyMon. Open the tool, start it, and head to the CPUs tab.
The reason I can say I have successfully bound my GPU to Core 5, dedicated USB controller for my 4K mouse to Core 6, and the other USB controller to Core 7 is because LatencyMon proves my statements.
You can easily confirm this by looking at the driver with the highest execution: Core 5 – NVIDIA process, and Core 6/7 bound to the driver responsible for USB devices. You can also easily confirm this by moving your mouse around and looking at the ISR/DPC counts. If you have bound the correct USB hub to your desired CPU core the ISR/DPC counts will increase as you move the mouse. If you have failed nothing will change. The same process applies to other devices.
The second tool which is less precise is HWiNFO. The process is quite similar where you look at the per-core CPU usage percentage while using the device you have bound actively. While moving my mouse in a hectic manner and spamming my keyboard you can see that the cores to which I have bound my USB controllers are experiencing higher percentage usage than the other cores in my CPU.
This is less precise because HWiNFO does not tell you which specific driver is using the cores, but if you have bound your device to one of the last cores and they suddenly experience higher usage than the first cores (which are usually the first to be used) then your affinity is set correctly.
TL;DR
Don’t fall for placebo tweaks and instead test if you have actually bound your desired device and set its affinity to a specific core. This is extremely useful because quite often you can’t be sure which device you need to bind to the core for it to work – is it the PCI-to-PCI bridge, the USB Root Hub, or maybe the device itself?
By testing each option and having the monitoring tools open (LatencyMon/HWiNFO), you can move the device around to different cores and confirm that you are changing its affinity in real time.
Do I also need to bind to the kernel thread?