Section 16.4. Scheduling

16.4. Scheduling

The dispatcher will always try to run the thread on its home lgroup if possible. If all the CPUs in the home lgroup are busy and running higher priority threads, the dispatcher will try to find the nearest CPU that is not busy. Even if a thread runs on a remote lgroup (an lgroup other than its home), its home lgroup will remain unchanged. The next time the thread is scheduled, the thread will try to return to its home lgroup if a CPU is available.

Dispatching a thread to its home locality group as often as possible is a critical component in improving performance through locality, along with locality aware memory allocation. Locality-aware scheduling reduces the number of internode cache-to-cache transfers. Avoiding remote cache transfers shortens the ramp-up time should a thread be migrated from one CPU's run queue to another. This sort of CPU migration occurs frequently in transaction-processing workloads, which run with thousands of threads that frequently sleep waiting on I/O.

Note that scheduling affinity is not done for real-time threads, since the implementation is POSIX conformant. Hence, jobs should be placed into timeshare (TS), interactive (IA), fixed priority (FX), or fair share (FSS) scheduling classes in order to benefit from MPO.

See Chapter 3 for more information on the dispatcher's implementation of locality group awareness.