Removing the Big Kernel Lock 222
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.'"
Linux? (Score:1, Funny)
Fascinating. (Score:0, Funny)
Re:Fascinating. (Score:5, Funny)
Re:Translation? (Score:5, Funny)
Re:Linux? (Score:0, Funny)
Re:Linux? (Score:4, Funny)
Re:Fascinating. (Score:3, Funny)
Keep off my lawn too, you pesky kernel hackers^WWkids
Re:Interesting (Score:5, Funny)
Re:Translation? (Score:3, Funny)
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!
Re:I don't understand (Score:5, Funny)
Re:Translation? (Score:4, Funny)
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.
Re:Linux? (Score:2, Funny)
We need MACRO kernels! (Score:2, Funny)
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.
Re:We need MACRO kernels! (Score:4, Funny)
Re:Fascinating. (Score:1, Funny)
Seriously, that stuff really complex, why don't they just do it in python, duh:
#!/bin/python
from kernels import Linux
So when can we run QNX-Ubntu? (Score:2, Funny)
Just asking . . .
Re:Linux? (Score:4, Funny)
On second thoughts, disregard that... I just remembered that Emacs has a Vi emultation mode!
Re:Sounds like the Linux kernel needs some tests.. (Score:3, Funny)
IANAKD? (Score:1, Funny)