Giant lock

The Big Kernel Lock, short BKL, was a technology that was introduced with Linux 2.0 in 1996 to manage the execution of kernel code by multiple processors or cores on multiprocessor systems. The BKL prevented multiple kernel (sub) processes are running at the same time (possibly on multiple cores / processors), and thus protected the kernel (or the hardware) before concurrent access to resources such as system files on the hard disk. Basically, the BKL was thus a spin lock, in which a feature to "disabled" sets a lock variable, as long as he is accessing the hard disk, for example.

History

BKL was introduced with 2.0 kernel (1996) to enable the use of multi -processor systems. After sacrificing performance (see problems ) had been established, the separate I / O Lock for the input / output subsystem was introduced in kernel 2.2. This splitting into smaller Locks for subsystems was continued until 2.6 ( last generation ), leading to very small Einzellocks ( so-called fine- grained locks, translates to " fine-grained locks " ) led, with which only small areas can be locked.

In kernel 2.6.37 BKL was generally and largely abolished with certain file system driver as the UDF driver the BKL still needed, but this is solved by patches in Linux 2.6.38. In the kernel compilation process, there is now a new option that allows the compilation is possible without BKL support. With version 2.6.39, support for BKL was finally removed from the kernel. New code should use the BKL in any case ( it would not be included in the official kernel )

Characteristics and usage

It is for users ( here in the sense of functions within the kernel) of the possible Locks, perform a blocking operation, or to sleep while the BKL held. However, the BKL is released automatically when the current user of the lock is displaced by the scheduler and re-enabled when the user is allowed to run again.

The BKL is a recursive lock, that is, it can be locked multiple times without causing a deadlock. To completely solve the lock, the lock must, however, be released again as often.

The benefits of the BKL is permitted only in process context. Unlike other spinlocks are not allowed to use the BKL in interrupt context.

In addition, the curls of the BKL disables kernel preemption, ie, the displacement of kernel threads by a scheduler. On uniprocessor machines off the BKL only the preemption without having an actual locking perform.

Syntax example:

Lock_kernel ();   / *   * Critical region;   * Here the actions can be performed, which must be lured * /   unlock_kernel (); Terms and deposits

In the source code of kernel 2.6 still existed despite the exit strategy is about 500 BKL calls ( lock_kernel ()).

This is because on the one hand, therefore, that in the depths of the kernel yet such calls are kept, reboot, for example, the calls () or sysctl (). Also ran the early boot process with activated BKL. Intensive BKL was also used by older file system drivers, including, inter alia, UFS, Coda, HPFS, FAT often used on portable storage media or the Minix file system. There are also individual processes such as the rpciod thread or core dump creation, use the BKL.

About 10 % of all lock_kernel () calls were in old and no longer used sound drivers and components of the kernel, whereas ALSA ( Advanced Linux Sound Architecture ), with one exception took no BKL calls.

Meanwhile, it is strictly forbidden to use the BKL in new code.

Problem

The problem of BKL was especially the extremely poor scalability - with kernel 2.0 and a system with only two processors were significant performance impact to be felt, and running on more processors is problematic. If the BKL has been used for a variety of data and code, could other regions of code that may completely different tasks completed, but the BKL used, not data or access their ( locked together with all other elements ) code ranges. For this reason, the BKL was converted into Locks for smaller areas, see history.

Another problem was obvious that it was absolutely unclear what is actually protected by a particular lock- call. What made ​​it difficult to replace by modern spinlocks was also that the BKL too often protected code instead of data, so it was difficult to determine what is actually curly.

In new code (variables ) or small groups of them used in each case, a single lock for individual data.