Big Kernel Lock
The Big Kernel Lock , or BKL for short , was a procedure 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 several kernel (sub) processes from running at the same time (possibly on several processors or processor cores) and thus protected the kernel (or the hardware) from concurrent access to resources such as system files on the hard disk . Basically, the BKL was thus a spin lock , a lock variable to "disabled" in which a function is, as long as they z. B. accesses the hard disk.
history
BKL was introduced with Kernel 2.0 (1996) to enable the use of multiprocessor systems. After performance losses (see problem ) had been identified, the separate I / O lock for the input / output subsystem was introduced with Kernel 2.2. This split into smaller locks for subsystems was continued until 2.6 (last generation), which led to very small individual locks (so-called fine-grained locks , translated as "fine-grained locks") with which only small areas could be blocked.
New code was not allowed to use the BKL under any circumstances (it would then not have been included in the official kernel), but a series of calls still existed for a long time. The BKL was largely abolished in the 2.6.37 kernel, although certain file system drivers such as the UDF driver still required the BKL, which was resolved by patches in Linux 2.6.38. There was then a new option in the kernel compilation process with which a compilation could be created without any BKL support. With version 2.6.39, the support for BKL was completely removed from the kernel, and the subsequent kernel was named "3.0". With this cleaning up, the BKL finally disappeared in 2011.
Properties and use
It is possible for users (here in terms of functions within the kernel) of the lock to carry out a blocking operation or to sleep while the BKL is held. However, the BKL is automatically released as soon as the current user of the lock is displaced by the scheduler and reactivated when the user is allowed to run again.
The BKL is a recursive lock, which means that it can be locked multiple times without triggering a deadlock. To completely release the lock, however, the lock must be released just as often.
The use of the BKL is only permitted in the process context. In contrast to other spinlocks, it is not permitted to use the BKL in the interrupt context.
In addition, the “lock” of the BKL deactivates kernel preemption , ie the displacement of kernel threads by a scheduler. On single-processor machines, the BKL only deactivates the preemption without actually performing any locking.
Syntax example:
lock_kernel();
/*
* Kritische Region;
* Hier koennen kritische Aktionen durchgefuehrt werden.
*/
unlock_kernel();
Use and occurrence
In the source code of kernel 2.6 still existed despite the exit strategy about 500 BKL calls ( lock_kernel()).
On the one hand, this is due to the fact that such calls are still retained in the depths of the kernel, for example for calls reboot()or sysctl(). The early boot process also ran with the BKL switched on. BKL was also used intensively by older file system drivers. a. UFS , Coda , HPFS , FAT , which is often used on portable storage media, or the Minix file system . There are also individual processes such as the rpciodthread or core dump creation that BKL use.
Around 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) did not use any BKL calls with one exception.
It is now strictly forbidden to use the BKL in new code.
Problem
The main problem with the BKL was its extremely poor scalability - with Kernel 2.0 and a system with already two processors, significant performance losses were felt, and running on even more processors is problematic. If the BCL was used for a wide variety of data and code, other code areas, which may have performed completely different tasks but used the BCL, could not access their data or code areas (which were locked together with completely other elements). For this reason the BKL was converted into locks for smaller areas, see story .
Another problem was obviously that it was absolutely unclear what is actually protected by a certain lock call. Also, what made it difficult to replace with modern spinlocks was that the BKL was protecting code instead of data too often , so it was difficult to determine what was actually being locked.
In the new code, a single lock is used for individual data (variables) or small groups of them.
Web links
- Linux kernel 2.6.37 released . pro-linux.de
- The Big Kernel Lock lives on . lwn.net
Individual evidence
- ↑ What's new in Linux 2.6.37 . heise.de
- ↑ Kernel Log 2.6.37 Architecture / Infrastructure
- ↑ Post from Linux Torvalds that the BKL-free UDF driver is too late for 2.6.37
- ↑ BKL: That's all, folks ( page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.
- ↑ Announcement mail from version 3.0-rc1 ( memento of the original dated November 30, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ^ Robert Love: Linux Kernel Development: A thorough guide to the design and implementation of the Linux kernel . Third edition. Addison-Wesley (Developer's Library), 2010, ISBN 978-0-672-32946-3 , pp. 198-199.
- ^ Post via the BKL
