Xbox One Game OS Physical Processor Scheduling
On the Xbox One, the Game OS of an exclusive resource application is configured as having either 6 or 7 processors.
In most cases, each of these Game OS processors (here after called Title CPUs) correspond 1-to-1 with a physical CPU. The first 4 CPU cores (CPU0-3) are assigned to Module 0 (Physical CPU0-3). The second 2 (or 3) CPU cores are assigned to Module 1 (Physical CPU4-7). There are two notable exceptions.
- The 7th core (CPU6) This processor is shared with the System OS (see Accessing a 7th Processing Core). The Host OS quickly toggles access to the physical processor between the Game OS and the System OS as necessary.
- Constrained mode When the Game OS is constrained, the Game OS processors that are mapped to Module 1 are reassigned (“folded”) on to Module 0. Similar to the 7th core, the Host OS quickly toggles access to the physical processor between the two Game OS processors as necessary.
Processor Time-slicing and scheduling quantum
In both circumstances where multiple OS processors are mapped to the same Physical CPU, each Title CPU is guaranteed at least 50% availability. This is implemented by time-slicing access to the physical CPU into time quanta in a manner very similar to thread scheduling in the OS. It is important to note that for time slices for which there is no active work (i.e. OS is swapped to idle), the physical CPU access is yielded even if the OS would have resumed processing on that CPU during that quantum. Time-slicing occurs at a very low level in the Host OS and neither the System OS nor the Game OS is aware of it happening. This means that title threads are not “pre-empted” and no context switch events occur. In other words, when a time slice is expired or gained, the currently scheduled thread continues to remain scheduled from the perspective of the Game OS.
Note For CPU6 in the unconstrained state, the System OS workload is maintained at < 20% of CPU power unless some specific processing, primarily, the Kinect voice recognition algorithm is activated (normally by the user saying “Xbox”, but can also occasionally be alerted in loud/noisy rooms).
During the constrained state, the exact balance of Physical CPU access is primarily dependent on the title code and threading behavior. The exact time slice quantum is subject to tuning for optimal performance and can vary depending on the workload of each OS. However, the upper bound of the quantum can be measured empirically and is in the low 100’s of microseconds (typically < 300us).
Monitoring and Measuring the effects of processor time slicing
Starting with the March 2015 XDK, the QueryProcessorSchedulingStatistics API can be used to perform real time measurements of the current processor scheduling behavior. The primary use case for this API is to enable measurements of the throttling rate of CPU6 so that titles can adjust workload appropriately. However, this API can also aid in profiling a title’s thread scheduling efficiency by computing the “idle time” of a CPU core.
A Title CPU is represented in the Host OS in 1 of 3 states: Running, Waiting, or Idle. QueryProcessorSchedulingStatistics returns back 3 values which characterize the distribution of time into each of the CPU states. These values pertain to the statistics of the Title CPU for which the API was called on.
| State | Definition |
|---|---|
| Running Time | The total time the processor has spent running title code |
| Global Time | Wall clock time |
| Idle Time | The total time the processor has spent not running or waiting for title code to run (time spent swapped to idle) |
| Waiting Time (not returned*) | The total time the processor has spent waiting to run title code |
It is important to know that these counters are not reset in deterministic (or, at least, not easily controlled) conditions so they should be treated in terms of delta from baseline measurements rather than absolute values. These 4 values are related as follows:
ΔRunning Time + ΔWaiting Time + ΔIdle Time = ΔGlobal Time
The values returned by QueryProcessorSchedulingStatistics update after each Physical CPU quantum is expired or yielded. For best results, values should not be compared for intervals smaller than 1-ms. It is also recommended that this API not be called faster than every 500-us (and ideally not faster than every 1-ms) to minimize the performance impact to the title.
(*) Although waiting time is not returned, it is easily calculated from the other values that are returned if necessary.
Computing Throttling Percentage (CPU6)
% Physical CPU Time = (ΔRunning Time + ΔIdle Time) / ΔGlobal Time
Physical CPU availability can be computed per the above equation. During normal operations, this value should consistently stay greater than 0.8 (80%). When throttling is activated this may drop. Although titles are guaranteed 50% of the physical CPU core, if the title yields its claim (by the OS swapping to idle), it is possible for this computation to return less than 0.5 (50%). By monitoring the results of the above calculation, titles can react in real-time to throttling changes in order to reduce CPU workloads.
Computing Idle Percentage (All CPUs)
% Idle Time = ΔIdle Time / ΔGlobal Time
Idle time can be computed per the above equation. Idle time occurs when the Game OS swaps to idle on any CPU core. This occurs primarily due to blocking calls where no other ready thread can be scheduled. Time spent in idle is essentially lost CPU cycles that could be used for processing additional title tasks. Should this value be higher than expected, it is a good indication that further profiling of context switching behavior (either WPA “precise CPU” view, or PIX Timing Captures) is warranted.