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.
Order by: Score:
The kernel...
by Tuishimi on Sat 21st May 2011 06:47 UTC
Tuishimi
Member since:
2005-07-06

...really just keeps getting better and better.

Reply Score: 4

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 UTC in reply to "Big Kernel Lock"
ndrw Member since:
2009-06-30

So they did. It's called Hurd.

Reply Score: 8

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

In that case its certainly not quicker!

Reply Score: 3

RE: Big Kernel Lock
by oiaohm on Sat 21st May 2011 12:35 UTC 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 Score: 2

RE[2]: Big Kernel Lock
by lucas_maximus on Sun 22nd May 2011 01:12 UTC 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 Score: 2

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

I think a stable ABI isn't favored by some important kernel devs, Greg Kroah-Hartman chief among them

Reply Score: 3

RE[4]: Big Kernel Lock
by lucas_maximus on Sun 22nd May 2011 10:08 UTC in reply to "RE[3]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

I read the reasoning behind it and every single point they make is actually the case for a Stable ABI.

It is a shame ... because my hardware works better on OpenBSD which is a niche Operating system than it does on Linux and I don't have pretty generic kit.

Reply Score: 2

RE[5]: Big Kernel Lock
by lucas_maximus on Sun 22nd May 2011 10:32 UTC in reply to "RE[4]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

That should be "do have generic kit"

Reply Score: 2

RE[3]: Big Kernel Lock
by lemur2 on Mon 23rd May 2011 01:36 UTC in reply to "RE[2]: Big Kernel Lock"
lemur2 Member since:
2007-02-17

"And the change in wisdom will start showing itself
Will this mean a stable driver ABI? "

A stable driver ABI is only required where you have a binary driver without source code.

To accomodate a stable driver ABI would mandate a lack of flexibility to change that ABI.

It is possible to hide anti-user features within a closed binary. It turns out that users don't want anti-user features. Linux is written by its users.

So, for at least these couple of reasons, a stable driver ABI is the exact opposite of what is wanted.

I read the reasoning behind it and every single point they make is actually the case for a Stable ABI.


So what part of "Linux is written by its users, and not by hardware OEMs or by big media wanting to include DRM" did you fail to understand?

my hardware works better on OpenBSD which is a niche Operating system than it does on Linux and I don't have pretty generic kit


This personal anecdote doesn't change the fact that Linux has working drivers for more hardware than any other OS.

Edited 2011-05-23 01:44 UTC

Reply Score: 3

RE[4]: Big Kernel Lock
by lemur2 on Mon 23rd May 2011 07:03 UTC in reply to "RE[3]: Big Kernel Lock"
lemur2 Member since:
2007-02-17

It is possible to hide anti-user features within a closed binary. It turns out that users don't want anti-user features. Linux is written by its users. So, for at least these couple of reasons, a stable driver ABI is the exact opposite of what is wanted.


I keep making this error ... it is not known as "anti-user features" but rather "anti-features". My apologies for getting the wrong term. Again.

A very good example of an anti-feature is the restrictions on skipping adverts and trailers in DVD players.

http://en.wikipedia.org/wiki/Damaged_good#Anti-features

"Whether a feature is an "anti-feature" often depends on the point of view of the observer: for example, the restrictions on skipping adverts and trailers in DVD players are anti-features from the consumer's viewpoint, but useful features from the viewpoint of the movie studio making the DVD which contains the codes that specify the restrictions".

Spot on. Anyway, since Linux is written by its users, it is written from the point of view that beimg unable to skip adverts and trailers when playing DVDs, or being unable to play a DVD bought in another country ... these kinds of features are bad.

Astute people will also notice that putting this kind of anti-feature into software requires that the software is closed source, and that the end user of such software is therefore unable to remove the anti-feature.

It is also useful to point out that there are vastly many more people who would NOT want this kind of anti-feature included in widely-used desktop software compared to the numbers of those who would want it included. Anyone who would argue ... want to put this to a vote?

Hence having a stable driver ABI is, indirectly, a bad thing, because a stable driver ABI allows for binary-only closed source drivers, and binary-only closed source drivers, in turn, allow anti-features.

A closed source binary-only driver is a "damaged good".

Edited 2011-05-23 07:12 UTC

Reply Score: 2

RE[5]: Big Kernel Lock
by lucas_maximus on Mon 23rd May 2011 13:51 UTC in reply to "RE[4]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

Oh not this crap.

You can go on all day about "anti-features" ... when my wireless/video/audio/<insert hardware> breaks after a kernel update ... I consider that to be an anti-feature.

Do you just parrot the crap that Stallman and Co come out with?

I have yet to hear a compelling technical argument as to why a Stable ABI is bad, most of the arguments are idealogical, which I care little for and don't link me that newsgroup post from the Kernel developer ... I've read it and it is complete crap.

Stable ABI means that the drivers are guaranteed to work even after kernel changes.

Edited 2011-05-23 13:52 UTC

Reply Score: 2

RE[6]: Big Kernel Lock
by Flatland_Spider on Tue 24th May 2011 12:34 UTC in reply to "RE[5]: Big Kernel Lock"
Flatland_Spider Member since:
2006-09-01

The whole point of not having a stable ABI is to get companies to release FOSS drivers for their hardware. Nothing more, nothing less.

If drivers didn't break every kernel change, or Xorg change, people wouldn't complain, and hardware companies wouldn't feel pressured to release FOSS drivers. It's a pretty good system really.

Reply Score: 1

RE[4]: Big Kernel Lock
by lucas_maximus on Mon 23rd May 2011 14:48 UTC in reply to "RE[3]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

To accomodate a stable driver ABI would mandate a lack of flexibility to change that ABI.


The whole point of an interface is that it does not change and the implementation below it changes ... this is standard software engineering practice.

It is possible to hide anti-user features within a closed binary. It turns out that users don't want anti-user features. Linux is written by its users.


Linux is not written by it's users, it is written by large corporations such IBM, Oracle, Redhat and Novell for their own personal needs

So, for at least these couple of reasons, a stable driver ABI is the exact opposite of what is wanted.


It is a common complaint that wireless drivers and video frequently break, this hasn't changed in almost 10 years (since I first used Linux).

So what part of "Linux is written by its users, and not by hardware OEMs or by big media wanting to include DRM" did you fail to understand?


Back to my previous point, much of the GNU/Linux development is done by large corporations, which develop it for their uses, not for the good of you or me ... this is why Desktop Linux has sucked for at least the last 10 years.

This idealogical argument becomes pretty moot, when there is no basement army of hackers improving the operating system, it is done by large corps for their benefit.

This personal anecdote doesn't change the fact that Linux has working drivers for more hardware than any other OS.


My point of it was obvious ... it is pathetic that an Operating system that has less than a 0.01% desktop install base support my hardware than is orders of magnitude far more popular OS and has far more developers.

Dismissing it as far as I am concerned means you can't concoct an explanation.

It is a common complaint that drivers frequently break on Linux, However it they don't frequently break on OpenBSD, Windows and Solaris, I know the latter two have a stable abi and I expect OpenBSD is the same.

Reply Score: 2

RE[5]: Big Kernel Lock
by No it isnt on Mon 23rd May 2011 21:19 UTC in reply to "RE[4]: Big Kernel Lock"
No it isnt Member since:
2005-11-14

It is a common complaint that drivers frequently break on Linux, However it they don't frequently break on OpenBSD, Windows and Solaris, I know the latter two have a stable abi and I expect OpenBSD is the same.


Is it? I only know of ATI's binary drivers, which are unavailable on OpenBSD and Solaris. Besides, they usually break due to changes in X.org, not the kernel, so if they were available for OpenBSD, they would break just as often.

Also, it would be nice if you checked whether OpenBSD really does have a stable kernel ABI, as discussing things based on guesswork and anecdote is a bit silly.

Reply Score: 2

RE[6]: Big Kernel Lock
by lucas_maximus on Mon 23rd May 2011 23:20 UTC in reply to "RE[5]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

I have the most generic intel chipset on this computer ... Linux doesn't work, OpenBSD does ... I honestly don't care whether it is Xorg, Linux or Space aliens ... I just want my damn video to work. I need a cheap unix system for deving on and I can't afford a mac (which if I could I would use that).

OpenBSD unlike Linux is an OS and not a kernel ... so Anything supported by version say 4.5 ... is going to guaranteed to work until you hit 4.6 as long as you follow stable and they release of working hardware with each release ... so you know what will work and what is not supported.

Same with Windows a driver will work from Windows XP RTM to Windows XP SP3 (I suspect there are the odd exceptions), A driver that will work with VISTA RTM will work with VISTA SP2 ... and so on.

Reply Score: 2

RE[7]: Big Kernel Lock
by No it isnt on Mon 23rd May 2011 23:28 UTC in reply to "RE[6]: Big Kernel Lock"
No it isnt Member since:
2005-11-14

OK, so you have no fucking clue whatsoever why your computer doesn't work, but you choose to blame the ABI. Fine.

You should have left it at stating your computer doesn't work and you have no fucking clue as to why.

Reply Score: 2

RE[5]: Big Kernel Lock
by lemur2 on Mon 23rd May 2011 23:24 UTC in reply to "RE[4]: Big Kernel Lock"
lemur2 Member since:
2007-02-17

"To accomodate a stable driver ABI would mandate a lack of flexibility to change that ABI.
The whole point of an interface is that it does not change and the implementation below it changes ... this is standard software engineering practice. "

Rubbish, utter rubbish. If there is a fault in the ABI itself, then it is the ABI which needs to change.

Like so:
http://www.phoronix.com/scan.php?page=news_item&px=OTQ3NA

Working around such faults in the ABI, just to keep the ABI stable, is exceptionally poor software engineering practice. The fault is still present. On Windows systems, such faults are frequently used to compromise the system.

Also, if one system has a stable ABI (which retains faults over a long period, and which is provided only so that anti-features may be hidden in the code), and another system has an upgradeable ABI (which is made possible becasue the code is open source), then eventually the latter system will overtake the performance of the former, even if the former had a few years head start.

Like so:
http://www.phoronix.com/scan.php?page=article&item=intel_snbsds_com...

Since the only thing that is inconvenienced by changes to the ABI is closed-source binary drivers, and Linux has open source drivers for far, far more hardware than any other OS, in the case of Linux it is far better to break the binary compatibility of the interface than it is to leave such a fault still present in the interface but reatin the ABI compatibility.

"It is possible to hide anti-user features within a closed binary. It turns out that users don't want anti-user features. Linux is written by its users.
Linux is not written by it's users, it is written by large corporations such IBM, Oracle, Redhat and Novell for their own personal needs "

Large corporations such IBM, Oracle, Redhat and Novell are indeed amongst the contributors to Linux. Large corporations such IBM, Oracle, Redhat and Novell are also amongst the users of Linux.

Linux is still written by its users.

"So, for at least these couple of reasons, a stable driver ABI is the exact opposite of what is wanted.
It is a common complaint that wireless drivers and video frequently break, this hasn't changed in almost 10 years (since I first used Linux). "

This has changed, as all major wireless manufacturers now provide open source drivers to the Linux kernel. The last problematic one was Broadcom.

http://arstechnica.com/open-source/news/2010/09/broadcom-announces-...

"So what part of "Linux is written by its users, and not by hardware OEMs or by big media wanting to include DRM" did you fail to understand?
Back to my previous point, much of the GNU/Linux development is done by large corporations, which develop it for their uses, not for the good of you or me ... this is why Desktop Linux has sucked for at least the last 10 years. This idealogical argument becomes pretty moot, when there is no basement army of hackers improving the operating system, it is done by large corps for their benefit. "

Large corporations are indeed amongst the contributors to Linux. Large corporations are also amongst the users of Linux. There is no use case for the large corporations who do contribute to Linux that is opposite to the use case that ordinary individuals use Linux for. The large corporations who do contribute to Linux cannot contribute anti-features, becase said corporations use Linux themselves and also because anti-features won't be accepted into the mainline kernel tree (because the code is open). Linux is still written by its users.

PS: As provided out of the box, current desktop Linux distributions beat the socks off all other desktops.

"This personal anecdote doesn't change the fact that Linux has working drivers for more hardware than any other OS.
My point of it was obvious ... it is pathetic that an Operating system that has less than a 0.01% desktop install base support my hardware than is orders of magnitude far more popular OS and has far more developers. Dismissing it as far as I am concerned means you can't concoct an explanation. It is a common complaint that drivers frequently break on Linux, However it they don't frequently break on OpenBSD, Windows and Solaris, I know the latter two have a stable abi and I expect OpenBSD is the same. "

Any time you install a new OS, be it a new version of Linx, be it Windows, Solaris or OpenBSD, you run the risk that parts of your system that used to work no longer do so. There was major breakage of hardware with Windows Vista, for example. Because Microsoft doesn't write the drivers, any hardware that is out of production is out of luck ... hardware OEMs aren't going to update drivers for old models they no longer sell. A huge number of printers, for example, had to be scrapped for lack of drivers after an update of Windows.

If you don't want Linux to break often, don't update the OS often. This is exactly the same for Windows.

Edited 2011-05-23 23:41 UTC

Reply Score: 2

RE[6]: Big Kernel Lock
by lucas_maximus on Tue 24th May 2011 09:49 UTC in reply to "RE[5]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

Working around such faults in the ABI, just to keep the ABI stable, is exceptionally poor software engineering practice. The fault is still present. On Windows systems, such faults are frequently used to compromise the system.


You depreciate it and keep it available giving people time to transition ... Google Maps still run V2 of the API even though it has been depreciated ... this gives people time to move over ... imagine if Google broke the API every few months, people would be pissed.

Also, if one system has a stable ABI (which retains faults over a long period, and which is provided only so that anti-features may be hidden in the code), and another system has an upgradeable ABI (which is made possible becasue the code is open source), then eventually the latter system will overtake the performance of the former, even if the former had a few years head start.


Not this anti-features bollox ... it is bullshit double speak. My hardware works better with OS that have a stable driver ABI.

Since the only thing that is inconvenienced by changes to the ABI is closed-source binary drivers, and Linux has open source drivers for far, far more hardware than any other OS, in the case of Linux it is far better to break the binary compatibility of the interface than it is to leave such a fault still present in the interface but reatin the ABI compatibility.


These evil closed source drivers make my hardware work well.

Linux is still written by its users.


** sigh **, missing the point as per usual.

This has changed, as all major wireless manufacturers now provide open source drivers to the Linux kernel. The last problematic one was Broadcom


Took too long ... lost me as a user. If there was a Stable driver ABI my wireless would have worked reliably years ago.

Large corporations are indeed amongst the contributors to Linux. Large corporations are also amongst the users of Linux. There is no use case for the large corporations who do contribute to Linux that is opposite to the use case that ordinary individuals use Linux for. The large corporations who do contribute to Linux cannot contribute anti-features, becase said corporations use Linux themselves and also because anti-features won't be accepted into the mainline kernel tree (because the code is open). Linux is still written by its users.


So how is improving performance for a clustering performance going to help my dual core laptop computer? It isn't. Those use-cases do not help me even remotely.

PS: As provided out of the box, current desktop Linux distributions beat the socks off all other desktops


That is a matter of personal opinion.

Any time you install a new OS, be it a new version of Linx, be it Windows, Solaris or OpenBSD, you run the risk that parts of your system that used to work no longer do so. There was major breakage of hardware with Windows Vista, for example. Because Microsoft doesn't write the drivers, any hardware that is out of production is out of luck ... hardware OEMs aren't going to update drivers for old models they no longer sell. A huge number of printers, for example, had to be scrapped for lack of drivers after an update of Windows.


One major breakage in Windows since Windows 2000 ... that is 8 years ... as opposed to major breakage everytime I update the OS.

If you don't want Linux to break often, don't update the OS often. This is exactly the same for Windows.


No, it is not the same for Windows ... between OS versions yes .. there can be breakage (not very often by the way), however in OS upgrades it is extremely rare.

Also are you seriously telling me to run an unpatched linux system? Are you nuts?

Reply Score: 2

RE[7]: Big Kernel Lock
by lemur2 on Tue 24th May 2011 10:00 UTC in reply to "RE[6]: Big Kernel Lock"
lemur2 Member since:
2007-02-17

Also are you seriously telling me to run an unpatched linux system? Are you nuts?


Are you seriously telling me that you would rather run closed binaries which no-one but the authors know how they work or what is in them? Are you nuts?

Are you seriously telling me that you are happy if an OEM provider of a binary blob driver happens to decide to suddenly drop support for perfectly good hardware that you own? You are perfectly happy to buy a new piece of hardware just because that suits an OEM? Are you nuts?

http://ubuntuforums.org/showthread.php?t=1372224
"For those of us who were stung last year by ATI's decision to drop support for <= R500 series cards from their closed source, or proprietary driver (known as the FGLRX driver), we are now forced to use the opensource ATI XORG driver. This is not as bad as it sounds, as in doing so, ATI has released a lot of the hardware specs on these older cards and the opensource driver has improved dramatically in the last year as a result."

Actually, it is more than just "not bad" ... some time ago the open source driver, which still supports R500 and earlier ATI GPUs, surpassed the performance of the last version of the proprietary fglrx driver that supported them.

Unlike Windows, Linux systems are not patched, they are re-compiled. Linux systems do not rely on binary compatibility.

You can install new kernels with only security updates without upsetting binary compatibility. This is what servers do, and even then only when strictly necessary. It is mostly not necessary, and servers achieve up-times in the order of years.

Here is a clue, this is news from 12 May 2011:
http://www.h-online.com/security/news/item/Ubuntu-Desktop-8-04-LTS-...

Edited 2011-05-24 10:16 UTC

Reply Score: 2

RE[7]: Big Kernel Lock
by lemur2 on Tue 24th May 2011 10:42 UTC in reply to "RE[6]: Big Kernel Lock"
lemur2 Member since:
2007-02-17

Not this anti-features bollox ... it is bullshit double speak. My hardware works better with OS that have a stable driver ABI.


Pffft. There is a vast array of discarded hardware out there which is on the rubbish tip ONLY because the OEM no longer supports it in favour of newer models. Your hardware doesn't work better on the rubbish tip ...

As for anti-features, they are real alright. Here is some light reading for you which just begins to touch upon the subject:

http://www.fsf.org/blogs/community/antifeatures
http://www.oscon.com/oscon2009/public/schedule/detail/8465
http://wiki.mako.cc/Antifeatures
http://www.geekzone.co.nz/foobar/6207
http://www.lifehacker.com.au/2010/01/antifeatures-wiki-catalogues-t...
http://www.eweek.com/c/a/Security/Microsoft-Rebrands-WGA-AntiPiracy...
http://www.reddit.com/comments/61alx/what_is_an_antifeature

The obvious common characteristic of anti-features is that they are found only in closed-source code.

Edited 2011-05-24 10:56 UTC

Reply Score: 2

RE[7]: Big Kernel Lock
by lemur2 on Tue 24th May 2011 11:37 UTC in reply to "RE[6]: Big Kernel Lock"
lemur2 Member since:
2007-02-17

Not this anti-features bollox ... it is bullshit double speak.


Hey look at this ... I found a table of Windows 7 anti-features published by none other than Microsoft themselves:

http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_...

Edited 2011-05-24 11:57 UTC

Reply Score: 2

RE[3]: Big Kernel Lock
by nej_simon on Mon 23rd May 2011 09:49 UTC in reply to "RE[2]: Big Kernel Lock"
nej_simon Member since:
2011-02-11

"And the change in wisdom will start showing itself


Will this mean a stable driver ABI?
"

That's no longer a large issue anyway, now when we have DKMS and similar systems.

Reply Score: 2

RE[4]: Big Kernel Lock
by lucas_maximus on Mon 23rd May 2011 14:49 UTC in reply to "RE[3]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

My wireless still breaks after a kernel upgrade ... So it is an issue.

Reply Score: 2

RE[5]: Big Kernel Lock
by nej_simon on Mon 23rd May 2011 20:23 UTC in reply to "RE[4]: Big Kernel Lock"
nej_simon Member since:
2011-02-11

My wireless still breaks after a kernel upgrade ... So it is an issue.


Well, are you using DKMS?

Reply Score: 1

RE[6]: Big Kernel Lock
by lucas_maximus on Mon 23rd May 2011 22:35 UTC in reply to "RE[5]: Big Kernel Lock"
lucas_maximus Member since:
2009-08-18

For example on my desktop I have nvidia card ... wait a sec DKMS doesn't work with that.

I have a ralink wireless chipset for some unknown reason doesn't have a Linux driver in the kernel (even though the hardware specs are available on ralink's website) ... OpenBSD supports it fine.

DKMS would never have to be ever invented if they bothered to make ABI stable.

Reply Score: 2

RE[7]: Big Kernel Lock
by No it isnt on Mon 23rd May 2011 23:26 UTC in reply to "RE[6]: Big Kernel Lock"
No it isnt Member since:
2005-11-14

In actual fact, DKMS does work with nvidia, but there is no binary-blob nvidia driver for OpenBSD, so your comparison is a bit shit.

Which RaLink do you use? Most of them are available through whatever distro you're using.

Reply Score: 2

RE: Big Kernel Lock
by raboof on Sat 21st May 2011 18:05 UTC 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 Score: 2

RE: Big Kernel Lock
by Elv13 on Sat 21st May 2011 19:17 UTC 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 Score: 3

RE: Big Kernel Lock
by tyrione on Sun 22nd May 2011 00:33 UTC 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 Score: 2

RE[2]: Big Kernel Lock
by bannor99 on Sun 22nd May 2011 00:56 UTC 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 Score: 2

RE[3]: Big Kernel Lock
by No it isnt on Sun 22nd May 2011 13:45 UTC in reply to "RE[2]: Big Kernel Lock"
No it isnt Member since:
2005-11-14

FreeBSD 5.0 was pretty much the KDE4 of FreeBSD, and I don't think it came good before 6.0 was out. It just wasn't very good.

Reply Score: 3

RE[4]: Big Kernel Lock
by bannor99 on Mon 23rd May 2011 05:56 UTC in reply to "RE[3]: Big Kernel Lock"
bannor99 Member since:
2005-09-15

Which they didn't make a secret of. It was clearly stated that 5.0 was breaking (lots of) new ground and there could be potential chasms.

http://www.freebsd.org/releases/5.0R/early-adopter.html

Reply Score: 2

RE: Big Kernel Lock
by galvanash on Sun 22nd May 2011 06:56 UTC 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 Score: 6

RE[2]: Big Kernel Lock
by bannor99 on Mon 23rd May 2011 17:57 UTC 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 Score: 2

What about the regressions?
by fasted on Sun 22nd May 2011 02:15 UTC
fasted
Member since:
2006-11-09

Long time Linux user, just curious about the recent power usage problems, Sandy Bridge problems, and Intel graphics regressions posted on Phoronics recently .
http://www.phoronix.com/vr.php?view=16015
http://www.phoronix.com/vr.php?view=15943
http://www.phoronix.com/vr.php?view=15935
New features are great, just wondering how bad regressions are, considering I have a netbook?

Reply Score: 1

Congratulations
by rafaelnp on Tue 24th May 2011 13:13 UTC
rafaelnp
Member since:
2009-06-03

Great news, specially on graphics.. ;)

Reply Score: 1