LWN.net Logo

Addressing latency problems in 2.6

Addressing latency problems in 2.6

Posted Jul 27, 2004 22:57 UTC (Tue) by simlo (subscriber, #10866)
Parent article: Addressing latency problems in 2.6

Why isn't spinlocks turned into real mutexes such they don't prevent
preemtion in general but only other threads from entering the protected area?
That way subsystem like ReifersFS or the console driver is not blocking the
whole system but only those threads/processes calling into those things. The multimedia players will still get scheduled if it has higher priority and don't enter those areas. Just as it would in a SMP machine on another CPU.


(Log in to post comments)

Addressing latency problems in 2.6

Posted Jul 31, 2004 4:28 UTC (Sat) by rlrevell (guest, #23596) [Link]

Because of the Big Kernel Lock, aka BKL. This was created as a way for the lazy to make old code 'SMP-safe' without having to implement proper, fine grained locking. This is a global lock, which differs from a spinlock in that it's recorsive and you can sleep while holding it. Unfortunately it disables preemption!

The problem with a facility like this is people will abuse it, because it's the easiest way to implement locking in your code, and before the kernel became preemptible, there was no cost to using the BKL vs. a proper lock on a UP. Many would have you think that the BKL is mostly a thing of the past, but it is still used, for example by ReiserFS for *all write locking*!

Many of the latency issues that have been eliminated recently in 2.6 involved eliminating or minimizing uses of the BKL. It has been suggested that the best way for a newbie to get up to speed on kernel hacking is to find a use of the BKL and replace it with a proper lock. Quoth Uresh Vahalia:

"System performance depends greatly on the locking granularity".

Lee

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds