Slashdot Mirror
Removing the Big Kernel Lock
Corrado writes "There is a big discussion going on over removing a bit of non-preemptable code from the Linux kernel. 'As some of the latency junkies on lkml already know, commit 8e3e076 in v2.6.26-rc2 removed the preemptable BKL feature and made the Big Kernel Lock a spinlock and thus turned it into non-preemptable code again. "This commit returned the BKL code to the 2.6.7 state of affairs in essence," began Ingo Molnar. He noted that this had a very negative effect on the real time kernel efforts, adding that Linux creator Linus Torvalds indicated the only acceptable way forward was to completely remove the BKL.'"
If this bores you, every lkml thread would cause your head to explode.
ResidntGeek
Its like rubbing cheetah blood on the engine of your car to make it go faster.
Obligatory blog plug: http://www.caseybanner.ca/
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Hey, its not easy keep every blade of grass within 0.3mm in length and maintain cross-colour length rules while keeping a close watch on weather-judged per-species expected length margins, you insensitive clod!
...
Keep off my lawn too, you pesky kernel hackers^WWkids
Caesar si viveret, ad remum dareris.
Yeah we got rid of the Giant lock, this is just the big lock, totally different things.
IranAir Flight 655 never forget!
And you learn more when you write your own (virtual) device driver which crashes your kernel and renders it to unbootable state :)
Not that I know anyone who has done so... or at least I wont admit it!
You don't know what you don't know.
Are you arguing for a microkernel style solution, sir? If so, I salute your bravery! ;-)
Linux is a preemptive multi-tasking kernel. What this means is that a hardware interrupt like a keyboard click or the system timer will interrupt whatever is currently running on the CPU, and an interrupt handler in the kernel starts running code. In order to make sure that all the states of the kernel are consistent (ie: not corrupt), the different parts of the kernel are supposed to lock the data that they are using or modifying (ie, readlock or writelock) in case another code path gets run at the same time trying to modify the same data. It becomes even more important in a multi-cpu environment where locks have to be atomic (happen at the same time on all CPUs). So what you are supposed to do is only lock the resources you currently need (a file system drivers would only lock parts of the filesystem, not a character device). Because some programmers are lazy, or not sure what they are doing, they just use the big kernel lock which locks pretty much everything in the kernel. This is bad for multi-tasking and multi-processing because it means you can only have one codepath using the lock at a time. Like putting too much air in a balloon!
#DeleteChrome
Specifically its just the bootloader for GNU Emacs, the finest most complete operating system known to mankind.
The best course of action would be to redesign the Linux kernel from scratch and this time integrate all possible drivers. Hardware support would be a lot easier!
I would even go so far as to suggest integrating the most important server tools into the kernel to decrease latency. Why not integrate Apache? You could even integrate the shell for added responsiveness!
Linus has demonstrated that micro kernels are a footnote in history. Nowadays memory is cheap and we can afford the have a large (or very large) kernel.
So when can we run QNX-Ubntu?
Just asking . . .
On second thoughts, disregard that... I just remembered that Emacs has a Vi emultation mode!
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
http://michaelsmith.id.au