This is an extension of the WindowsIoT CSP Soft Real-Time Performance configuration and assumes you have read the documentation. SetRTCores
essentially prevents interrupts and tasks from being scheduled on reserved cores so that you can isolate real-time applications from user and kernel-level disturbances by configuring affinity policies.
Important
Unexpected behavior occurs when a process affinity is set to reserved and unreserved CPUs. Ensure to set the affinity to either reserved or unreserved CPUs, not a combination of both. See #2 for more information.
-
Launch the program and select the CPUs you wish to reserve and save changes
-
After a restart, verify whether the configuration is working as expected by assessing per-core usage while placing load on the CPU with a program such as CpuStres. The reserved cores should be underutilized compared to the unreserved cores
This program aims to circumvent the limitations of the PowerShell script in the documentation by:
-
Allowing customization of the bitmask instead of the configuration being limited to reserving the last N consecutive cores
-
Revert the changes
-
Adding support for earlier Windows 10 versions
Upon inspection of system changes while configuring SetRTCores
to 11 with the PowerShell script, the registry key below was created. After a few minutes of reverse engineering, the explanation for the value is relatively simple (see examples).
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\kernel]
"ReservedCpuSets"=hex(3):FE,0F,00,00,00,00,00,00
Adding support for earlier versions of Windows 10 involves utilizing NtSetSystemInformation as demonstrated in CpuSet from Windows Internals.
111111111110
corresponds to the bitmask for reserving the last 11 cores on a 12 core system. Converting the bitmask to hexal little endian results in FFE
. Converting that value to hexal big endian results in FE0F
. Hence, the registry value of FE,0F,00,00,00,00,00,00
.
11100000
corresponds to the bitmask for reserving the last 3 cores on an 8 core system. Converting the bitmask to hexal little endian results in E0
. Converting that value to hexal big endian results in E0
. Hence, the registry value of E0,00,00,00,00,00,00,00
.
Since the registry value originates from an affinity bitmask, I have confirmed that it can be customized instead of the configuration being limited to the last N consecutive cores. Below is an example of 10101010
.
The documentation does not provide information as to how the value can be reverted to default. Since we are aware that a registry value is changed and does not exist by default, we can determine whether deleting the registry entry reflects in a local kernel debugger such as WinDbg by reading KiReservedcpusets
.
Write-Host $obj.SetRTCores // 0
lkd> dd KiReservedcpusets L1
fffff807`216fdc10 00000000
Write-Host $obj.SetRTCores // 3
lkd> dd KiReservedcpusets L1
fffff807`216fdc10 000000e0
Write-Host $obj.SetRTCores // 0
lkd> dd KiReservedcpusets L1
fffff807`216fdc10 00000000
In the program, reverting the changes is equivalent to unchecking all CPUs then saving changes.