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.
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
ReservedCpuSets
registry entryWrite-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.