Processor affinity

From Wikipedia, the free encyclopedia

Processor affinity is a modification of the native central queue scheduling algorithm. Each task (be it process or thread) in the queue has a tag indicating its preferred / kin processor. At allocation time, each task is allocated to its kin processor in preference to others.

Processor affinity takes advantage of the fact that some remnants of a process may remain in one processor's state (in particular, in its cache) from the last time the process ran, and so scheduling it to run on the same processor the next time could result in the process running more efficiently than if it were to run on another processor.

Actual scheduling algorithm implementations vary in how strongly they will adhere to processor affinity. Under certain circumstances some implementations will allow a task to change to another processor if this is deemed to be most efficient under the circumstances. An obvious example involves two processor-intensive tasks (A & B) having affinity to one processor while another processor lies unused. Many algorithms would shift task B to the second processor in order to maximize processor utilization. Task B would then acquire affinity with the second processor while task A would continue to have affinity with the original processor.

Processor affinity can effectively reduce cache problems but it does not curb the persistent load-balancing problem. ^[1]

Processor affinity becomes more complicated in systems with non-uniform architectures. As an example, a system with two dual-core hyper-threaded CPUs presents a challenge to a scheduling algorithm. There is complete affinity between two virtual CPUs implemented on the same core via hyper-threading; partial affinity between two cores on the same physical chip (as the cores share some, but not all, cache), and no affinity between separate physical chips.

Processor affinity alone cannot be used as the basis for dispatching processes to specific CPUs, however, as other resources are also shared. For instance, if a process has recently run on one virtual hyper-threaded CPU in a given core, and that virtual CPU is currently busy but its partner is not, cache affinity would suggest that the process should be dispatched to the idle partner. However, since the two virtual CPUs compete for essentially all computing, cache, and memory resources, it would typically be more efficient to dispatch the process to a different core or CPU if one is available; while this would likely incur a penalty in that the process would have to repopulate the cache, overall performance would likely be higher as the process would not have to compete for resources such as functional units within the CPU.

On Linux the CPU affinity of a process might be altered with the taskset(1) program. ^[2] On SGI systems, dplace binds a process to a set of CPUs.^[3] On Windows NT, thread and process CPU affinities can be set separately by using SetThreadAffinityMask^[4] and SetProcessAffinityMask^[5] API calls.