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

Trent · 2009-09-23 00:49:43

I was a bit amused by the shocked response of the article's author to Torvalds's comment. I mean, I kind of thought it was obvious -- nobody will argue that the kernel has only gotten smaller and faster over the years, right? And some of that is inevitably "bloat" by someone's definition. At least Linus has a realistic view of things, unlike some who responded to the article.

As for microkernels -- I think they're a good idea, but they as yet have no market presence (well, Windows is now allegedly a microkernel design, although how one would test this theory I have no idea). Minix is predominantly used for education purposes, and I don't see how it could become viable for other uses without compromising that goal. Hurd is stagnant (not development-wise but user-wise), and shows no evidence of picking up. <speculation>I think the best chance for an open source microkernel to break into wide use is for the Linux devs to move it in that direction. Make it a long-term goal, like say version 4.0, and start to pull things out of the kernel proper gradually. It would certainly be a lot of work, but I think it will happen eventually. Or we might even see Linux split into a microkernel Linux and a monolithic Linux. Boy would that be the fork of the decade </speculation>

AngryKoala · 2009-09-23 01:53:25

Trent wrote:

As for microkernels -- I think they're a good idea, but they as yet have no market presence (well, Windows is now allegedly a microkernel design, although how one would test this theory I have no idea).

Windows and OSX are not microkernels, hence they still have driver crashes and BSODS. Windows and OSX use hybrid kernels, which is basically a monolithic kernel reverse engineered to look like a microkernel. However, they could not place file system management and drivers outside the kernel, so if a driver crashed, the kernel would still crash.

Minix places the filesystem, memory management, and drivers in "user space" so if anything goes wrong with those components, the kernel is unaffected and it would just restart those processes. As of now, minix is being developed at a snails pace and is not popular...but I can see the value of it and its design.

Ranguvar · 2009-09-23 02:59:54

See, this is why Linux (well, open source) rocks: instead of the CEO (lead dev) waving his arms and reassuring us that everything's just peachy, Linus frankly addresses issues and works to get them solved.
Wootness!

As an aside, I blame hardware manufacturers for not standardizing as much as they should

I just hope this doesn't lead to everyone "just giving up" and going with the Apple model of closed hardware which the OS is specifically targeted at, which will screw hardware progress enormously.

And to quickly do preventive, post-op, damage control:
1.) OS X is _not_ a microkernel, as AngryKoala said. It was based on a microkernel, sorta, but it's nothing like a microkernel anymore.
2.) Microkernels are NOT the be-all end-all for stability. But they do rock, and hopefully create a situation where the kernel is _least_ likely to die, so individual apps can be restarted with much less pain.
3.) Microkernels CAN become stupendously stable though... for example, I remember (perhaps badly) that they're trying to get Minux now to be able to complete a typical, send-once, large file transfer from ethernet to hard disk -- while repeatedly and purposefully killing the ethernet and hard drive drivers. The drivers just automatically restart with _no_ user or process interruption. Daaaamn. I want that on my video card, naow!

Last edited by Ranguvar (2009-09-23 03:00:59)

shining · 2009-09-23 06:41:35

How often do your drivers crash ?

Aprz · 2009-09-23 07:40:23

techprophet wrote:

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.

With gzip compression mine is 1.6M, and 1.4M with lzma. I use lzma compression. It's a static kernel/module-less. Just felt like bragging. I think it still doesn't fit on a floppy cause it's slightly smaller than 1.5M really (not dead on 1.4M or even low 1.4M). Oh well. *sigh*, don't want to cut features (that's lame sauce).

I think the biggest problem I have with microkernels vs monolithic vs hybrid is that we experience slow downs with just modules in hybrids so if the entire thing is modular then I can imagine it being very sluggish. Like shining said, how often does your drivers crash (or anything really...)? To this day the only kernel panic I've experienced are after I have baked a fresh kernel and forgot something vital. I experience like nothing wrong unless I have caused it with a foolish mistake... With Windows or with non custom things then I might experience something here and there without any reasonable reason.

Anyhow, this doesn't seem to affect me since I compile my kernel. The source code is giant! I've been reading books on different parts of the Linux kernel, articles on different drivers, schedulers, concepts, whatever.... It's huge... Like said earlier though, this seems to only affect the guys who are trying to make it work for their group of users. Folks who use custom kernels (like me) already know what they need support for and go directly into that (doesn't matter how big it is, I know my way around and what I need).

Last edited by Aprz (2009-09-23 07:42:28)

AngryKoala · 2009-09-23 08:24:26

The slow down from microkernels being modular is pretty much fixed. It was slow when they first came out, but microkernels were scrapped and then redone from scratch and the lag has mostly been made up for with simple interprocess communication. My drivers crash in Linux a couple times a year. My drivers crash enough in Windows enough to make me not want to see my favorite color. Gamers see BSOD's all the time, and I work on many, many laptops that cant start up due to a single driver.

The point is that a simple driver should not make my whole computer crash. Isn't that a good principle? I mean we expect perfection from a TV or microwave. Why can't my computer be expectedly reliable? Like Ranguvar said microkernels are not the solution to all our computing stability needs, but its a step in the right/better direction if we are looking from purely the stability perspective. It's true that the monolithic kernel is doing just fine right now, and I'm typing and posting just fine right now, but the benefit may be greater than the pain of readjusting our way of thinking, especially for windows users.

Also, hybrid kernels are attempts to create microkernels, but they used the old method, which, they found out was bad. Windows and Apple took monolithic kernels and stripped them to try to make microkernels. They had terrible performance becuse they could not solve the interprocess communication problem. Andrew Tannenbaum rewrote the whole thing from scratch and solved the IPC problem, bringing microkernels back up to speed. Earlier I said how i.e. giving one process all the memory and having all other processes request from that process so that no communication is necessary between user space processes and the kernel, therefore perhaps even making it faster than a monolithic kernel since no context switch is ever necessary.

Ranguvar · 2009-09-23 19:50:50

I've had panics due to NVIDIA drivers multiple times before with Ubuntu, and once with Arch.

Microkernel speed slowdown is about 10% IIRC, and even that some microkernels have managed to eliminate (L4 was an experimental microkernel that ran the Linux kernel as a process, and achieved very near-native speeds).
I'll gladly pay a 10% speed loss for increased stability.
What I'm worried about is the supposed increase in kernel hacking difficulty with a microkernel. That was one big argument of Torvalds, that microkernels only _seem_ simple and are actually much harder to program. If this is true, then monolithic all the way -- to quote Steve Ballmer (ugh): "Developers, developers, developers, developers!!" There haven't been any projects with real motive to work on being desktop- or server-ready though (except for the overall failure that was Mach, using old kernel design)... don't try to figure this one out based on Minux for example, which isn't really intended to be a production OS any time soon. It's intended to show off how stable computers _could_ be. A research project.

I think it's preposterous to say that Linux should "switch" to a microkernel design (no, nobody has said that here yet). Linux should keep on truckin', and we'll see where other projects go.

AngryKoala · 2009-09-23 20:51:11

It's true that microkernels would be much much harder to hack and develop independently. However, what exactly would you need to hack in it since it would be stripped down? Minix3's kernel is something like 4000 lines of code.

Ranguvar · 2009-09-24 01:05:19

Hey, I'm not that experienced with kernel development I'm just repeating what others have said along with a grain of salt.

But to try and answer your question, how about the scheduler? Debates over that quickly become legendary on the Linux side of things, and it's quite a "hot spot".
Also, I imagine that all the drivers that were kicked out of the kernel still need to be written, perhaps it is harder to do so with a microkernel.

Again, I'm no kernel hacker.

Last edited by Ranguvar (2009-09-24 01:07:12)

AngryKoala · 2009-09-24 03:44:30

I've never really sat in a debate about schedulers =/ nor do I know much about them. Being one who just wants something that doesn't crash I'm biased towards stability. Also, it would probably be better (evil chuckle) to make drivers harder to write since many of the current ones are causing such nasty problems. Of course it just might cause even more problems so I'll let the developers do what they want and just fantasize about easily developed modular subsystems.

Ranguvar · 2009-09-24 05:37:13

AngryKoala wrote:

I've never really sat in a debate about schedulers =/ nor do I know much about them. Being one who just wants something that doesn't crash I'm biased towards stability. Also, it would probably be better (evil chuckle) to make drivers harder to write since many of the current ones are causing such nasty problems. Of course it just might cause even more problems so I'll let the developers do what they want and just fantasize about easily developed modular subsystems.

... try Googling "Con Kolivas". Have fun xD
Here's a few links to get you started on the latest scheduler wars:
http://bbs.archlinux.org/viewtopic.php?id=79398&p=1
http://thread.gmane.org/gmane.linux.kernel/886319 (massive thread)
http://lwn.net/Articles/351058/ (read the comments)

And I agree with you on the modularity bit, but just to reiterate, Linus's argument is that microkernels only get you _perceived_ modularity. Anyways.

iphitus · 2009-09-24 10:25:51

Before you go on with the microkernel debate, maybe clarify what linus was saying.

I don't think he was talking about having 'large numbers of drivers to support a lot of hardware' -- I don't consider that bloat, and I don't think it's the bloat he was referring to.

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

Linus appears to be talking more about the kernel core, not the drivers around it.The microkernel debate just isn't relevant here, and is more philosophical anyway.

It'll be interesting to see if the comment is followed up on LKML, if at all and what steps are taken to make it more efficient.

Arch Linux

#26 2009-09-23 00:49:43

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

#27 2009-09-23 01:53:25

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

#28 2009-09-23 02:59:54

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

#29 2009-09-23 06:41:35

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

#30 2009-09-23 07:40:23

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

#31 2009-09-23 08:24:26

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

#32 2009-09-23 19:50:50

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

#33 2009-09-23 20:51:11

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

#34 2009-09-24 01:05:19

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

#35 2009-09-24 03:44:30

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

#36 2009-09-24 05:37:13

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

#37 2009-09-24 10:25:51

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

Board footer