Lock totals in 2.5

So why are the lock totals increasing?

There are two counts that are increasing. The first is the number of global spinlocks. This is increasing slowly because of the way developers, even in an unstable "development" tree like 2.5, prefer to phase in new locking. As some of the major bottlenecks are addressed, the old locks are not removed until the developer is sure that doing so will not have undesirable side effects. Meanwhile, new locks are created in the new code to take over the old functions. We should expect the number to (just as slowly) go down as 2.5 comes to a close and 2.6 comes out.

The other count increasing is the number of files utilizing the BKL (Big Kernel Lock). There is a similar although not identical effect happening here. In several cases, it has been determined that a function no longer needs to use the BKL. However, that function calls several other functions, often defined in separate device drivers, which the fixing coder doesn't know very well. He doesn't know if those drivers (incorrectly) depend on the locking that is being discarded. In order to keep broken code to a minimum, the grabbing of the BKL is pushed down to the functions below it and it is left up to a later effort or the maintainers of that code to determine whether it is also safe to remove it from those functions. Thus "removing" the BKL from one function might cause it to appear in five others. In theory, however, the correctness of those five functions should be easier to determine and that code, then, quickly cleaned up. (In practice, it's not always so quick.)

If maintainers are conscientious, the number of files using the BKL will slowly decrease. If not, they will stay steady until somebody makes a significant effort to clean up all the code at once, as Dave Hansen did between 2.5.0 and 2.5.1.