At this point the BKL doesn't cause much performance loss: "The Big Kernel Lock is a giant lock that was introduced in Linux 2.0, when Alan Cox introduced SMP support for first time. But it was just an step to achieve SMP scalability - only one process can run kernel code at the same time in Linux 2.0, long term the BKL must be replaced by fine-grained locking to allow multiple processes running kernel code in parallel. In this version, it is possible to compile a kernel completely free of BKL support. Note that this doesn't have performance impact: all the critical Linux codepaths have been BKL-free for a long time. It still was used in many non-performance critical places -ioctls, drivers, non-mainstream filesystems, etc-, which are the ones that are being cleaned up in this version. But the BKL is being replaced in these places with mutexes, which doesn't improve parallelism (these places are not performance critical anyway). " From http://kernelnewbies.org/LinuxChanges#head-67c8ee4ffc27a012ae3d5349377b1dc44... On Wed, Jan 5, 2011 at 8:38 PM, Bernardo Barros <bernardobarros2@gmail.com> wrote:
2011/1/5 Ng Oon-Ee <ngoonee@gmail.com>:
At this point in time leaving it enabled for compatibility in kernel26 is fine IMO. Those who need it disabled for specific reasons (the one I can think of is task latency for audio) should already be used to compiling patched kernels, so it wouldn't be a big deal for now.
+1 for patched kernels for audio (including kernel26-rt) in community
-- Alexander Lam