In multiprocessor computer systems, software lockout is the issue of performance degradation due to the idle wait times spent by the CPUs in kernel-level critical sections.[1] Software lockout is a major cause of scalability degradation in a multiprocessor system, posing a limit on the maximum useful number of processors. To mitigate the phenomenon, the kernel must be designed to have its critical sections as short as possible, therefore decomposing each data structure in smaller substructures.

Kernel-level critical sections

In most multiprocessor systems, each processor schedules and controls itself, so there is no "supervisor" processor,[1] and kernel data structures are globally shared; sections of code that access those shared data structures are critical sections. This design choice is made to improve scaling, reliability, and modularity.[1] Examples of such kernel data structures include ready lists and communication channels.

A conflict happens when more than one processor tries to access the same resource (a memory location) at the same time. To prevent race conditions and inconsistency, only one CPU at a given time is allowed to access a particular data structure, while other CPUs trying to access it at the same time are locked out and wait in idle status.[1][2]

Three cases can be distinguished, in which idle waiting is either necessary, acceptable, or undesirable. Idle waiting is necessary when access is to a ready list for a low-level scheduling operation. It is acceptable in the case of a critical section for synchronization or IPC operations, which take less time than a context switch (which would itself be required to execute another process in place of idle waiting). Idle waiting is undesirable in the case of a kernel critical section for device management, a situation that arises mainly in monolithic kernels. A microkernel design only encounters the first two cases.

In a multiprocessor system, most conflicts are kernel-level conflicts due to access to kernel-level critical sections, and the resulting idle wait periods have a major impact on performance. The cumulative idle wait time increases the average number of idle processors and reduces scalability and relative efficiency.

Analytical studies

Taking as parameters the average time interval spent by a processor in kernel-level critical sections (L, for time in locked state), and the average time interval spent by a processor in tasks outside critical sections (E),[1] the ratio L/E is crucial in evaluating software lockout.

Typical values for L/E range from 0.01 to 0.1.[1] In a system with an L/E ratio of 0.05, for instance, with 15 CPUs, one CPU on average will always be idle; with 21 CPUs, 2.8 will be idle on average;[3] with 40 CPUs, 19 will be idle; with 41 CPUs, 20 will be idle.[1] Adding more than 40 CPUs to that system therefore yields little benefit. In general, for each L/E value, there is a threshold for the maximum number of useful CPUs.

Software lockout mitigation

To reduce the performance degradation of software lockout to acceptable levels (L/E between 0.05 and 0.1), the kernel and operating system must be designed accordingly. The most direct approach is to decompose each kernel data structure into smaller independent substructures with shorter access times, allowing more than one CPU to access the original data structure concurrently.

Many uniprocessor systems with hierarchical protection domains have been estimated to spend up to 50% of their time performing supervisor mode operations. If such systems were adapted for multiprocessing by setting a single lock around any access to supervisor state, L/E would easily exceed 1,[1] resulting in throughput similar to the uniprocessor system regardless of the number of CPUs added.

Modern operating system kernels mitigate software lockout using techniques such as fine-grained locking, lock-free data structures, read-copy-update (RCU) synchronization, and per-CPU data structures, which together allow contemporary kernels to scale to large numbers of processors.[4]

See also

References

  1. ^ a b c d e f g h Madnick, Stuart E. (1968). Multi-processor software lockout (PDF). Proceedings of the 1968 23rd ACM National Conference. pp. 19–24. doi:10.1145/800186.810561.
  2. ^ Saltzer, Jerome (June 1966). Traffic control in a multiplexed computer system (PDF) (PhD). MIT Project MAC MAC-TR-30.
  3. ^ Raynor, Randy J.; Gwynn, John M. Jr. (July 1976). "Minimization of supervisor conflict for multiprocessor computer systems". ACM SIGSIM Simulation Digest. 7 (4): 61–69. doi:10.1145/1013610.807300.
  4. ^ McKenney, Paul E. (2017). Is Parallel Programming Hard, And, If So, What Can You Do About It? (2nd ed.). Linux Technology Center, IBM.

Further reading

  • Dubois, M.; Briggs, F. (November 1991). "The run-time efficiency of parallel asynchronous algorithms". IEEE Transactions on Computers. 40 (11): 1260–1266. doi:10.1109/12.102830.
  • Rodgers, David P. (June 1985). Improvements in multiprocessor system design. Proceedings of the 12th Annual International Symposium on Computer Architecture (ISCA '85). ACM SIGARCH Computer Architecture News. Vol. 13, no. 3. pp. 225–231. ISSN 0163-5964.
  • Cordsen, Jörg; Schröder-Preikschat, Wolfgang (November 23–27, 1992). Towards a Scalable Kernel Architecture. Proceedings of the Autumn 1992 Openforum Technical Conference. Utrecht, Netherlands. pp. 15–33.
source: https://en.wikipedia.org/wiki/Software_lockout