Linked by Elv13 on Fri 20th May 2011 21:06 UTC
Linux Version 2.6.39 once again took Linus Torvalds and his fellow developers less than 70 days to complete. This is further indication of a slight, though ever more apparent, increase in the kernel's development speed, as about 80 to 90 days still passed between the release of two versions one or two years ago. With 2.6.39, this also meant that there was a slight decrease in the number of advancements which are worth mentioning in the Kernel Log; however, there are still plenty of changes that will make Linux faster and better.
Thread beginning with comment 474098
To read all comments associated with this story, please click here.
Big Kernel Lock
by Brendan on Sat 21st May 2011 09:56 UTC
Brendan
Member since:
2005-11-16

Hi,

Some interesting stats:
- 1991 Linux kernel started
- 1996 (5 years later) "Big kernel lock" added as a quick hack to get it working on SMP systems
- 2011 (15 years later) "Big kernel lock" finally removed completely

It would've been quicker to rewrite it from scratch in 1996, instead of attempting to retro-fit SMP support on a kernel that wasn't originally designed for it; especially when you consider that the number of contributors would've been far less in the earlier years.

- Brendan

Reply Score: 1

RE: Big Kernel Lock
by ndrw on Sat 21st May 2011 10:15 in reply to "Big Kernel Lock"
ndrw Member since:
2009-06-30

So they did. It's called Hurd.

Reply Parent Score: 8

RE[2]: Big Kernel Lock
by J.R. on Sat 21st May 2011 11:07 in reply to "RE: Big Kernel Lock"
J.R. Member since:
2007-07-25

In that case its certainly not quicker!

Reply Parent Score: 3

RE: Big Kernel Lock
by oiaohm on Sat 21st May 2011 12:35 in reply to "Big Kernel Lock"
oiaohm Member since:
2009-05-30

Some interesting stats:
- 1991 Linux kernel started
- 1996 (5 years later) "Big kernel lock" added as a quick hack to get it working on SMP systems
- 2011 (15 years later) "Big kernel lock" finally removed completely

This leaves out what went wrong. Where more and more code end up protected by the BKL even if it really did not require it.

Rewrite from scratch for SMP still could have ended up a huge mess. Core developers today are a lot wiser than the were even 5 years ago.

And the change in wisdom will start showing itself.

Reply Parent Score: 2

RE[2]: Big Kernel Lock
by lucas_maximus on Sun 22nd May 2011 01:12 in reply to "RE: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

And the change in wisdom will start showing itself


Will this mean a stable driver ABI?

Reply Parent Score: 2

RE: Big Kernel Lock
by raboof on Sat 21st May 2011 18:05 in reply to "Big Kernel Lock"
raboof Member since:
2005-07-24

It would've been quicker to rewrite it from scratch in 1996, instead of attempting to retro-fit SMP support on a kernel that wasn't originally designed for it


Interesting theory.

Of course, it's impossible to tell if what you claim is actually true, because in the 1996-2011 period a lot happened besides removing BKL.

Reply Parent Score: 2

RE: Big Kernel Lock
by Elv13 on Sat 21st May 2011 19:17 in reply to "Big Kernel Lock"
Elv13 Member since:
2006-06-12

It would have ended up like KDE4, Linux was in early adoption stage back then. If they added a massive amount of regressions only to be able to evolve faster a few years later, Linux would have died. It was not yet strong enough to survive that.

*I love KDE4, but don't deny the early problem it had.

Reply Parent Score: 3

RE: Big Kernel Lock
by tyrione on Sun 22nd May 2011 00:33 in reply to "Big Kernel Lock"
tyrione Member since:
2005-11-21

Hi,

Some interesting stats:
- 1991 Linux kernel started
- 1996 (5 years later) "Big kernel lock" added as a quick hack to get it working on SMP systems
- 2011 (15 years later) "Big kernel lock" finally removed completely

It would've been quicker to rewrite it from scratch in 1996, instead of attempting to retro-fit SMP support on a kernel that wasn't originally designed for it; especially when you consider that the number of contributors would've been far less in the earlier years.

- Brendan



Just 8 years longer than what transpired on FreeBSD.

Reply Parent Score: 2

RE[2]: Big Kernel Lock
by bannor99 on Sun 22nd May 2011 00:56 in reply to "RE: Big Kernel Lock"
bannor99 Member since:
2005-09-15

For those who don't know or remember how the SMP improvements in FreeBSD came about, Greg Lehey's talk from 2003 is worth reading.

http://www.lemis.com/grog/SMPng/Singapore/slides.pdf

While many of us (myself included) view free vs commercial as a contest, they do benefit from one another.

Reply Parent Score: 2

RE: Big Kernel Lock
by galvanash on Sun 22nd May 2011 06:56 in reply to "Big Kernel Lock"
galvanash Member since:
2006-01-25

It would've been quicker to rewrite it from scratch in 1996, instead of attempting to retro-fit SMP support on a kernel that wasn't originally designed for it; especially when you consider that the number of contributors would've been far less in the earlier years.


I would argue that if they had done what you suggest in 1996, Linux would be nothing but a memory now of something that might have been. Seriously - that would have killed all forward progress on the kernel for at least a year or more.

Trying to go straight from a non-preemptive unicore kernel directly to a preemptive one with fine-grained locking would have been a disaster imo. That is something you want to do slowly and carefully. Even with the BKL "hack" Linux scaled well enough on dual processor hardware, which was what most people were running and was enough to get it by for a while (obviously).

Sure, it wasn't competitive with Solaris and such on big hardware for a long time - but most people didn't care because they were not running Linux on such hardware... No, it wasn't ideal - but reality often requires one to compromise their ideals in the name of getting things done. As Linus is fond of saying, "perfect is the enemy of good".

I'm just happy the people managing the project knew better and didn't try to bite off more than they could chew...

ps. You left out that they started the process of removing the BKL about 6 or 7 years ago. It wasn't done overnight, and about 75% of the scalability gains in doing so have been realized for at least 5 years.

Edited 2011-05-22 07:06 UTC

Reply Parent Score: 6

RE[2]: Big Kernel Lock
by bannor99 on Mon 23rd May 2011 17:57 in reply to "RE: Big Kernel Lock"
bannor99 Member since:
2005-09-15

They could have done it with a separate release like FreeBSD did - 4.x for stability, 5.x for new SMP.

That might also have allowed Linux to get the TTY layer rewrite in years earlier (is that even complete as yet?)
and we might still have Alan Cox maintaining it, who's probably been more important to the improvements in Linux than any single person incl Torvalds himself.

Reply Parent Score: 2