"We're getting bloated and huge. Yes, it's a problem." - Torvalds

Xyne · 2009-09-22 15:00:26

I saw this article on Slashdot today which focuses on a comment made by Linus Torvalds at LinuxCon in Portland, Oregon. Here's an article with more quotes and some context (also linked on the /. page).

Do you agree or disagree with Linus?
Have you noticed the alleged 12% cumulative performance drop mentioned in Intel's internal study of the last 10 releases?
Do you think this can or will be addressed or is it not even an issue?

Give some context to your answers too. It would be interesting to see if desktop users view things differently than server admins or embedded system developers.

shining · 2009-09-22 15:14:28

I guess I stand corrected then : http://bbs.archlinux.org/viewtopic.php? … 87#p613087

Do you have a link to Intel's internal study ? Any other comparison of this kind ? Links welcome.

Also where does Linus mention performance at all ? The only thing he says is :

Sometimes it's a bit sad that were are definitely not the streamlined, small hyper efficient kernel I envisioned 15 years ago. The kernel is huge and bloated and our iCache footprint is scary. There's no question about that, and whenever we add a new feature, it only gets worse

So he just talks about iCache footprint here, whatever that is.
Found here : http://news.ycombinator.com/item?id=836435

"our icache footprint" means "the number of instruction cache lines occupied by kernel code".

Xyne · 2009-09-22 15:23:02

The /. article links to this article on The Register. There they mention the internal study which was cited by Bottomly (the moderator at the roundtable discussion).

If someone finds a complete transcript, post a link.

flamelab · 2009-09-22 15:38:46

The problem is that: check out on git.kernel.org, on linus' branch (the main branch). You'll see other branches merging into it every day. Even though they are tagged as "fixes", it's a huge amount of data.

Nevertheless, Linux can't be bloated. As long as we can remove things from config and even create a reaaaaally minimal kernel, that can't be true.

[rant] Well, he uses Fedora, that's the definition of bloatness [/rant]

combuster · 2009-09-22 15:55:02

I agree that ones with custom kernel are not affected by this. Distro's out there (including Arch) are having trouble to optimize and @the same time support as many hardware as it is possible.

I don't think that since 2.6.21 kernel dropped in performance by 12% , but if intel tests says it's true then... ;-)

flamelab · 2009-09-22 15:56:23

I really don't know what Intel wants to prove with that, maybe they want more access and patches to the kernel in order to improve it their way

scj · 2009-09-22 16:15:22

Battlestations! Someone said something negative of the linux kernel and we must defend it's honor!

Anonymo · 2009-09-22 16:27:05

scj wrote:

Battlestations! Someone said something negative of the linux kernel and we must defend it's honor!

The creator has turned on the creation. It's Frankenstein all over again.

pseudonomous · 2009-09-22 16:40:24

flamelab wrote:

I really don't know what Intel wants to prove with that, maybe they want more access and patches to the kernel in order to improve it their way

I don't see why intel would necessarily want to be proving anything with their study, it could just be an instance of them tracking kernel development, which they'd be interested in since they're fairly interested in Linux development so that you can run linux with their hardware.

If they say there's been a performance decline, they're probably right. But the article linked doesn't say exactly where/what the decline is. Is it an increase in memory usage? Decrease in i/o? Increased time for execution of programs? Some composite of various factors? And can you do anything about it by changing your kernel config?

Anyways, as Torvalds says "It's unacceptable, but pretty much unavoidable"; I don't want to use windows, even if I wanted to I couldn't afford to buy a Mac (nor do I want to screw around w/ Hackintoshing), and I'll bet anything that Linux performance is still comparable or better for Desktop and small-scale server usage than either Solaris or FreeBSD, with way more hardware compatibility and more native software.

techprophet · 2009-09-22 17:21:49

Default kernel is bloated. The code is huge! I understand it supports everything but my Creative Zen...but it's still huge.

Bloated, on the other hand, is a matter of perspective.

My custom gentoo kernel was 3.2M last I checked.

combuster · 2009-09-22 17:28:52

Mine is 1.9MB but everything is better then a zillion compiled modules and unecessary drivers in the kernel image.

I guess Intel used this one: http://software.intel.com/en-us/intel-vtune/

Atsutane · 2009-09-22 17:39:09

I think he meant the Codebase not what you get after building it, because this is definitely bloated, but that's not so easy to avoid for a monolithic kernel(Mr. Torvalds says so too.), so I wonder if Mr. Tenenbaum sents Mr. Torvalds a "Told you so." Email.

(Not that I want to offend anyone, I have great respect for both, but as the old discussion just was topic in a MUC in the last days I couldn't resist.)

smartboyathome · 2009-09-22 17:58:27

WARNING! The following may rehash an age old debate. It is not my intention to turn this thread into a flamewar or anything to get the topic locked.

The problem lies not in the kernel itself, but in the model. Monolithic kernels will always be big and bloated unless you compile out the stuff you don't need. Hybrid kernels still have this problem, as you still have to delete modules at compile time. Microkernels have everything separated from the kernel, so if you don't need something it isn't part of the kernel, it isn't used, and can be gotten rid of safely. This is why I want Minix to succeed.

FSM · 2009-09-22 18:19:55

If some of you have problems with this monolithic (therefor huge bloated) kernel, I think GNU Hurd over there needs some developers and testers

ammon · 2009-09-22 18:24:44

Whats with http://aur.archlinux.org/packages.php?ID=17373?

If this is functional? Why not to use it by default?

smartboyathome · 2009-09-22 18:41:19

ammon wrote:

Whats with http://aur.archlinux.org/packages.php?ID=17373?
If this is functional? Why not to use it by default?

You still have to recompile the kernel to get rid of all the code that isn't required by your hardware. That would add hours upon hours to the install, depending on hardware. Plus, I doubt that is perfect, and some stuff that you need could get compiled out.

Xyne · 2009-09-22 18:46:03

pseudonomous wrote:

If they say there's been a performance decline, they're probably right. But the article linked doesn't say exactly where/what the decline is.

That's what I thought too. It would be interesting to know what exactly they were measuring.

Atsutane wrote:

I think he meant the Codebase not what you get after building it

He probably did, but without the full context it's difficult to know. The Intel study came up though so the discussion about bloat can't have been limited to the source code itself.

smartboyathome wrote:

WARNING! The following may rehash an age old debate. It is not my intention to turn this thread into a flamewar or anything to get the topic locked.

There shouldn't even be a risk on this board for a flame war over such a topic. I would hope that Archers are mature enough to realize that something can be good or even great yet still have shortcomings that could be improved. It's not just black and white.

smartboyathome wrote:

The problem lies not in the kernel itself, but in the model. Monolithic kernels will always be big and bloated unless you compile out the stuff you don't need. Hybrid kernels still have this problem, as you still have to delete modules at compile time. Microkernels have everything separated from the kernel, so if you don't need something it isn't part of the kernel, it isn't used, and can be gotten rid of safely. This is why I want Minix to succeed.

What have the Linux devs said about this? Would they do it the same way if they could go back to the beginning?

I would a expect project the size of Linux to be frustrating. The sheer size of it and the number of projects that depend on it must mean that many things would be prohibitively difficult to change even if there were a truly better way to do them.

Square · 2009-09-22 18:53:27

The only performance drop I've seen with recent kernels is a performance drop from Intel graphics drivers, and that's about it.

As far as the kernel getting bloated, perhaps it is true. Look at the most popular distributions' kernels. They're not exactly slim and sexy, now, are they?

Themaister · 2009-09-22 19:00:50

A huge kernel base isn't really a problem. Not removing unnescessary stuff from the kernel is one though.

shining · 2009-09-22 19:30:02

Xyne wrote:

pseudonomous wrote:
If they say there's been a performance decline, they're probably right. But the article linked doesn't say exactly where/what the decline is.
That's what I thought too. It would be interesting to know what exactly they were measuring.

IMO this is a crucial information which is lacking, and it makes all discussion completely worthless.
We are talking/arguing about something which is not clearly formulated and explained...

smartboyathome wrote:
The problem lies not in the kernel itself, but in the model. Monolithic kernels will always be big and bloated unless you compile out the stuff you don't need. Hybrid kernels still have this problem, as you still have to delete modules at compile time. Microkernels have everything separated from the kernel, so if you don't need something it isn't part of the kernel, it isn't used, and can be gotten rid of safely. This is why I want Minix to succeed.
What have the Linux devs said about this? Would they do it the same way if they could go back to the beginning?

from the tuxradar article, linked from slashdot :
http://www.tuxradar.com/content/linuxco … lds-quotes

On user-space driver frameworks reducing kernel bloat:
"But you certainly would not want to take an existing kernel filesystem and then move it into user space. that would just be crazy. That's LSD trippy, kind of. Don't do that. A lot of the time it gets way harder to debug, we're moving things into the kernel out of user space because of issues like that. We're doing kernel mode setting, and doing a lot more of the logic of graphics in kernel space, actually makes it a lot easier for everybody because now you don't have two broken pieces that don't have a clue what the other piece is doing, and trying to debug across that kind of divide is horrible. The debugging advantages of doing drivers in user space have always been kind-of suspect. I don't think it's really been true, except in very early kind of bring up meaning. Now people can do. You can do block devices in user space, you can do character device drivers in user space, you can do filesystems in user space. Go wild. It's not, I think, relevant for any major filesystem or driver but it's there if you want to. Now Greg can disagree with me."

About microkernel vs macrokernel, this is the great Tanenbaum vs Torvald debate !
http://en.wikipedia.org/wiki/Tanenbaum% … lds_debate

As mentioned on wikipedia, the debate restarted in 2006, which led to several slashdot articles that year.
For example :
http://tech.slashdot.org/article.pl?sid … 10/0439246
The second comment there :

Linus FTFA:
"The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms.
And anybody who tells you that distributed algorithms are "simpler" is just so full of sh*t that it's not even funny.
Microkernels are much harder to write and maintain exactly because of this issue. You can do simple things easily - and in particular, you can do things where the information only passes in one direction quite easily, but anythign else is much much harder, because there is no "shared state" (by design). And in the absense of shared state, you have a hell of a lot of problems trying to make any decision that spans more than one entity in the system.
And I'm not just saying that. This is a fact. It's a fact that has been shown in practice over and over again, not just in kernels. But it's been shown in operating systems too - and not just once. The whole "microkernels are simpler" argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. By a huge amount, too.
The whole argument that microkernels are somehow "more secure" or "more stable" is also total crap. The fact that each individual piece is simple and secure does not make the aggregate either simple or secure."

So Linus has a lot to argue on the microkernel vs macrokernel debate

Xyne · 2009-09-22 19:50:04

thanks, shining

fijam · 2009-09-22 21:59:18

As with every discussion the meaning of some crucial words should be clearly defined. For example, I do not necessarily think that "bloatness" is a problem. With more drivers / architectures supported there will obviously be more code. As long as maintainers of all subsystems can keep up with fixing bugs, this should not result in degraded quality of the kernel. It is entirely different story if the maintainers cannot keep up with the pace of development, but I do not want to discuss it here. The real question for me is: is there any overhead introduced by that code?

And performance-wise, the kernel seems to be degrading. There are occasional smart fixes that bring immediate several % increase in performance in certain scenarios but in general... Well, see for yourself:

http://kernel-perf.sourceforge.net/resu … ions=.html
http://www.ioremap.net/node/37 and related: http://thread.gmane.org/gmane.linux.network/108268

Another question arises. Is this caused merely by the rapid addition of new code? Or perhaps there is a deeper problem?

From my layman point of view, fixing performance regressions is not something the developers like. It requires a lot of work to find what usually turns out to be a tiny change in a part of the kernel that nobody thought of. It's a long, boring process involving lots of bisecting, compiling and benchmarking that few people like to do voluntarily. And it does not add a new feature, merely restores status quo giving little bragging rights and personal satisfaction. As a result (as could be seen in the thread linked above) the developers sometimes turn a blind eye or put a blame on someone else.

Can something be done about it? I suppose that hope might be in big distributions that have the required manpower and infrastructure. Corporations like Novell or Red Hat already report regressions but perhaps more (Canonical?) could join in and not only occasionally *report* a regression with steps how to reproduce it but take take the responsibility of narrowing it down to the commit that caused it. This way the developers would have more incentive to fix it.

There is one more problem inherent to the way the kernel is developed. People. Unfortunately, some decisions are still being made not only basing on technical merits but also on personal familiarities. I am not going to bring up specific examples, because that could easily erupt in a flamewar, I am bringing this up only to highlight the problem.

Allan · 2009-09-22 23:34:26

smartboyathome wrote:

ammon wrote:
Whats with http://aur.archlinux.org/packages.php?ID=17373?
If this is functional? Why not to use it by default?
You still have to recompile the kernel to get rid of all the code that isn't required by your hardware. That would add hours upon hours to the install, depending on hardware. Plus, I doubt that is perfect, and some stuff that you need could get compiled out.

Not perfect, but close for my laptop (where I last checked it out). It compiled in some modules I did not think I needed so I guess it try for false positives rather than false negatives.

AngryKoala · 2009-09-23 00:05:04

One of the major appeals for a microkernel to me is its memory design. The kernel creates a process that has ALL the memory and the rights to it all. The process accepts or denies other process' requests for more memory. Of course you can blacklist processes and such, but lets keep it simple for now. If a driver fails, the memory process fails and the kernel restarts it. I know that is a very simplistic view of it and I'm no kernel dev, but I like the idea. Anyone else see the appeal?

ljshap · 2009-09-23 00:33:12

AngryKoala wrote:

One of the major appeals for a microkernel to me is its memory design. The kernel creates a process that has ALL the memory and the rights to it all. The process accepts or denies other process' requests for more memory. Of course you can blacklist processes and such, but lets keep it simple for now. If a driver fails, the memory process fails and the kernel restarts it. I know that is a very simplistic view of it and I'm no kernel dev, but I like the idea. Anyone else see the appeal?

Arch GNU/minux ?

Arch Linux

#1 2009-09-22 15:00:26

"We're getting bloated and huge. Yes, it's a problem." - Torvalds

#2 2009-09-22 15:14:28

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#3 2009-09-22 15:23:02

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#4 2009-09-22 15:38:46

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#5 2009-09-22 15:55:02

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#6 2009-09-22 15:56:23

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#7 2009-09-22 16:15:22

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#8 2009-09-22 16:27:05

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#9 2009-09-22 16:40:24

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#10 2009-09-22 17:21:49

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#11 2009-09-22 17:28:52

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#12 2009-09-22 17:39:09

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#13 2009-09-22 17:58:27

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#14 2009-09-22 18:19:55

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#15 2009-09-22 18:24:44

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#16 2009-09-22 18:41:19

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#17 2009-09-22 18:46:03

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#18 2009-09-22 18:53:27

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#19 2009-09-22 19:00:50

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#20 2009-09-22 19:30:02

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#21 2009-09-22 19:50:04

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#22 2009-09-22 21:59:18

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#23 2009-09-22 23:34:26

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#24 2009-09-23 00:05:04

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

#25 2009-09-23 00:33:12

Re: "We're getting bloated and huge. Yes, it's a problem." - Torvalds

Board footer