什么是Processor affinity

最新推荐文章于 2024-07-11 15:43:27 发布

kkk8000

最新推荐文章于 2024-07-11 15:43:27 发布

阅读量8.3k

点赞数 2

分类专栏：操作系统文章标签： freebsd resources cache 任务 algorithm thread

操作系统专栏收录该内容

14 篇文章 0 订阅

订阅专栏

处理器关联(Processor affinity)是一个本地队列中央在对称多处理操作系统调度算法的改进。每个任务（无论是进程或线程）在队列中有一个标记，表明其首选/健处理器。在分配时，每个任务分配给其关联处理器优先于其他处理器。

处理器关联注意到一个事实，即一个进程上一次运行的数据残留会保存在一个处理器内（尤其是在它的缓存），所以调度到同一处理器上运行会比调度到另一个处理器运行效率更高效。

实际调度算法实现非常复杂多变。在某些情况下将允许一些实现任务切换到另一个处理器。一个明显的例子涉及到两个处理器密集型任务（A和B），关联一个处理器，而另一个处理器为空闲。许多算法将转移任务B到第二个处理器，以最大限度地提高处理器的利用率。任务B将与第2个处理器关联，同时任务A将继续与原来的处理器关联。

处理器关联，可有效降低高速缓存的问题，但它不遏制持续负载平衡问题。 [1]

处理器关联是一个复杂和不统一的架构体系。作为一个例子，有两个双核超线程CPU的系统提出了一个调度算法的挑战。有完整的关联之间通过超线程相同的核心实现了两个虚拟CPU;两个核心部分的关联在同一个物理芯片（共享为部分缓存，但不是全部），两个单独的物理芯片是没有管理的。

处理器关联不能单独用来作为特定的CPU调度程序，但是基础，也为其他资源共享。例如，如果一个进程，最近在一个虚拟超线程CPU在一个给定的核心，而虚拟CPU运行正忙，但它的另一个虚拟CPU空闲。于是缓存关联建议，这一进程应该派遣到空闲的另外一个cpu。不过，由于两个虚拟CPU基本上所有的计算，高速缓存和内存资源进行竞争，它通常是更有效地调度到一个不同的进程核心或CPU，而这将可能招致的性能消耗是这进程必须重新填充缓存。

在Linux上的一个进程的CPU关联可能会改变与包括taskset（1）程序。 [2]在SGI系统，dplace绑定进程的CPU设置。[3] NetBSD的5.0，7.2和更高版本的FreeBSD可以使用pthread_setaffinity_np和pthread_getaffinity_np [4]。在NetBSD中，psrset效用[5]设置线程的亲和力，在一定CPU设置。在FreeBSD，cpuset的[6]实用工具用于创建和指定CPU的设置过程，以这些集。在Windows NT中，线程和进程的CPU的关联，可单独使用SetThreadAffinityMask [7]和SetProcessAffinityMask [8] API调用或可以通过任务管理器设定每个进程的的关联。 Mac OS X的公开API，它提供了一个关联提示，内核根据关联设置调度线程执行。

================================================================================

原文如下：

Processor affinity

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Processor affinity is a modification of the native central queue scheduling algorithm in a symmetric multiprocessing operating system. 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. A practical example might be running multiple instances of an application which does not use multiple threads, such as some graphics-rendering software. Overall system efficiency increases by reducing performance-degrading situations such as cache misses.

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] NetBSD 5.0, FreeBSD 7.2 and later versions can use pthread_setaffinity_np and pthread_getaffinity_np^[4]. In NetBSD, the psrset utility^[5] to set a thread's affinity to a certain CPU set. In FreeBSD, cpuset^[6] utility is used to create CPU sets and to assign processes to these sets. On Windows NT, thread and process CPU affinities can be set separately by using SetThreadAffinityMask^[7] and SetProcessAffinityMask^[8] API calls or can set each process's affinity via the Task Manager interface. Mac OS X exposes an affinity API that provides hints to the kernel how to schedule threads according to affinity sets.