Scrutinizing Global Locks


Patches to reduce global locks and BKL usage.
Lock counts and documents for releases in 2.4 tree
Lock counts and documents for releases in 2.5 tree

Why bother? Global locks, that is to say, locks not declared static and available to all modules, are the most likely candidates to be misused and inadvertently cause bottlenecks. On multiple-cpu systems, misusing even a single global lock can cause unintended performance degradation. While it may be impossible to eliminate ALL global locks, every one that does exist should be scrutinized closely to see if it truly needs to be global -- or is truly needed at all. (It is not uncommon to find that locking has been maintained out of fear rather than out of understanding, and analysis can reveal opportunities to rearchitect locking so that it is both correct and scalable.)

Is it really that big a deal? How many global locks are there? There is still in use the Big Kernel Lock (BKL, or kernel_flag as it is known in the kernel.) This springs from the days in Linux when it was believed that, by and large, one lock could cover all the locking situations. With the advent of multiple-cpu machines, it became apparent that there were many situations where a finer-grained approach would yield better performance. The 2.4 tree in particular has applied this philosophy with great success, but there are still hundreds of use of the BKL in the kernel. As of the release of 2.4, there were still over a hundred separate global spinlocks and read/write locks.

So what does this document do? It simply lists the global locks and what (apparently) they guard. It is presented as a guide to someone who has carefully considered using a global lock and decided it is appropriate to use one. With this document, at least, they can make sure they are using it correctly.

It is a good thing to reduce the number of global locks. For all but the most expert, they are pitfalls waiting to be fallen into. So in the table below, there is also an indication of how many global locks were remaining in that release. As you can see, they are slowly decreasing.

What version is the locking document based on? A version of the locking document exists for most 2.4 releases, although there are some gaps. Comments regarding the content, or new information to include in it, may be sent to nevdull (Rick Lindsley). It is the author's intent that the document be updated about once a quarter, which at the last observed rate of 2.4 releases, should correspond to slightly less often than every release.

Are there any patches that have come out of this? Yes. Some spinlocks are global when they can obviously be made static. These are low-risk changes that can be applied now to reduce the number of global locks. Patches to reduce the scope of these locks (make them static) are listed below. In most cases, these patches have been sent to the maintainers and are expected to appear in future releases. Some have already started to appeared in new releases (they are noted below; those patches no longer need be applied after the indicated release.) The patches are version-independent so long as they are applied against 2.4.x releases.

While these may seem small or inconsequential, they add up. The fewer global locks there are, the fewer misuses can occur, and the easier that performance analysis becomes for other points of contention.

Return to LSE home page.

Comments/questions to nevdull

Last updated: 6/1/02

SourceForge Logo