Processor Core Allocation and Performance Monitoring

The following topics are discussed in this section.

• Processor Core Allocation
• Performance Monitoring

Processor Core Allocation

The Xbox One console contains two processor modules, each of which has four processor cores. The cores on a processor module share L2 cache memory and bandwidth to main memory, and L1 and local L2 cache hits have substantially lower latency than L2 cache hits on the other processor module, or cache misses that result in a fetch from main memory. The System partition reserves one processor core for shared apps and system functionality such as NUI processing. The app running in the Exclusive partition is allocated the other seven cores for its use. Of the seven Exclusive partition cores, cores 0-3 occupy an entire processor module, and cores 4, 5, and 6 share a processor module with the cores allocated to the System partition. Cores 4, 5, and 6 are subject to contention for L2 cache space and main memory bandwidth with the system core, which can affect performance on those three cores. You should not allocate memory-intensive threads to cores 4, 5, or 6 for this reason.

Input/output-intensive threads, and threads that copy large amounts of data originating from shared apps or the system should be allocated to cores 4, 5, and 6. Game logic and memory-intensive worker threads that do not share data with shared apps or the system, should be allocated to cores 0-3.

A thread is assigned to a core as soon as the thread becomes ready to run. The thread is assigned to an idle core if one is available. If multiple idle cores are available, the scheduler tries to avoid moving threads between cores and CPU modules. If there are no idle cores available, the thread is assigned to a core chosen by the operating system at thread creation time.

To lock a thread to a particular subset of cores, use the core identifiers listed above to set thread processor affinity using SetThreadAffinityMask.

Note It is currently not possible to specify which core a lambda will run on.

Performance Monitoring

This section introduces performance monitoring counters (PMCs), events, and thread affinitization.

CPU core performance monitoring counters

Each CPU core in the Xbox One contains four hardware PMCs. These counters can be configured to count one of a number of events relating to the core and its execution. In this way, the core can potentially monitor many different events, but only any four of these events at any one time.

Prior to the August 2013 XDK, these event counts were only shown by the PIX System Monitor — this display switches the events being counted on each core and generates averaged data on a per second basis. For micro-optimization of specific pieces of code, per second aggregated views are less useful; for this situation, from the August 2013 XDK onwards, game titles can configure and read the per-core PMCs.

Configuring the counters with events

Title code can map hardware events to each of the PMCs using this call:

HRESULT ConfigurePMCs(unsigned int eventIndex0, unsigned int eventIndex1, unsigned int eventIndex2, unsigned int eventIndex3);  

The parameters to this call are indexes to a table of hardware events. The first event index is assigned to the first PMC. For example, this call configures PMC 0 to count retired instructions, PMC 1 will count L1 data cache misses, PMC 2 will count mispredicted branches, and PMC 3 will count data TLB misses.

HRESULT result = ConfigurePMCs(14,3,16,6);  

The PMCs on all available cores are configured to count the same events. See the section about cores and affinitization below to understand the implications.

When title code calls ConfigurePMCs , it takes ownership of the counters from PIX. PIX System Monitor will no longer be able to configure the counters and display per-second counts for the whole set of counters. It is assumed the title code configuring the counters takes precedence over PIX. In a later XDK, a mechanism to hand ownership back to PIX will be provided.

Reading event counts from the PMCs

PMCs hold an unsigned 64-bit total of the event they are configured to count. Title code can read that value like this:

UINT64 count;
GetPMCValue(0,&count);  

The first parameter is the index of the PMC to be read. The valid range is 0 to 3 — there are only four PMCs on the core. This value is not the event index — remember the core can only count four of the possible events at any one time.

Code calling GetPMCValue before ConfigurePMCs will be returned zero values.

Cores, counters, and thread affinitization

ConfigurePMCs sets the PMCs on all cores to count the same events. However, each core has separate PMCs; this means differencing or comparing event counts from different cores is meaningless.

Threads that are not hard affinitized to a single core using SetThreadAffinityMask can be migrated between cores by the OS scheduler. If you have a thread reading PMC values that is not hard affinitized, it will get discontinuous or incorrect values across the period it migrates cores.

For example, imagine configuring PMC 0 to count L1 data cache misses. If core 1 runs threads that cause many data cache misses, and core 4 runs threads causing very few misses, the event totals will be completely different on the two cores. If a thread reads PMC 0 on core 1 then is moved to core 4 by the OS, then reads PMC 0 on core 4 and differences the values, even though both PMCs are counting data cache misses, an incorrect picture of data cache misses will result.

When a title is set to PLM constrained state, CPU cores 4, 5, and 6 are reclaimed by the system; title threads running on those cores are forcibly migrated to cores 2 and 3. In the same way as the example above, reading PMCs across this change will result in a false picture as those threads may read PMCs from different cores.

Be aware PMC values can give a false picture in these two scenarios.

Hardware events

The event index provided to ConfigurePMCs should be taken from the table below. ConfigurePMCs will return E_INVALID_ARG if the index is out of range.

See also

Thread API Reference