Consequently, whenever a processor adds a line of data to its local cache, all the other processors in the system also caching it must invalidate that data but this invalidation is costly.īut the real performance penalty comes into play when processes bounce between processors as they constantly cause cache invalidations, and the data they want is never in the cache when they need it. Data can be kept in only one processor’s cache at a time otherwise, the processor’s cache may grow out of sync. Multiprocessing computers try and keep the processor caches valid. a highly threaded application, it makes sense to enforce the affinity as a hard requirement. The scheduler tries hard to keep tasks on the same processor, but in some performance-critical situations, i.e. The first benefit of CPU affinity is optimizing cache performance. If a processor is bound to CPU 1, for example, then it can run only on CPU 1. It is a requirement, and processes must adhere to a specified hard affinity. Hard affinity, on the other hand, is what the CPU affinity system call provides. The scheduler bounces processes between multiple processors each time they are scheduled and rescheduled.

This behavior results in the ping-pong effect. On the opposite end, however, is the Linux 2.4.x scheduler (admittedly an old kernel), which has poor CPU affinity.

The O(1) scheduler exhibits excellent natural affinity. It is merely an attempt if it is ever infeasible, the process is migrated to another processor. The first, soft affinity (also called natural affinity) is the tendency of the scheduler to try to keep processes on the same CPU as long as possible.

Affinity photo linux