I wish to look at the Linux kernel. I am interested in the size of the kernel.

The bulk of the kernel consists of hardware drivers but these are modules and are optionally loaded depending on the config.

What are peoples' view on the remainder of the kernel in terms of the size of it?

Is it possible to trim anything further?

Another point is, does size correspond to efficiency or any performance benefit?

I'm not an expert by any means, just an observer so I hope I can chime in.

Has grown huge over the last decade.

It is possible to create a micro kernel.

Size in some ways may be related to speed but not as much as most people think I'd imagine. Not like the OS has to read the kernel from the drive every few seconds.

I'm amazed that more people don't jump on the MenuetOS concept of machine language OS.

Unless you are in a very constrained environment (embedded maybe), who cares ?.
Have a look in dmesg after a boot, and see what the kernel is actually occupying. In the general run-of-the-mill modern computer it is insignificant.

So the constraint of an environment is just a question of memory space then?
I've been hearing a number of complaints lately about the condition of Linux becoming too bloated or Windows like.

MenuetOS is an interesting idea. Although I imagine it's very architecture specific which is why the phone industry say has opted for something like Android for embedded devices like smartphones.

I must admit it is possible to tell, subjectively, the decreasing responsiveness of a system as new Linux kernels are introduced. For example there is a definte decrease in system responsiveness with later kernels if you compared say Kernel 3.02 versus 3.14. Newer kernels feel 'slower'. The upside is that sometimes later kernels introduce better efficiency through improved implementation but the overwhelming trend is a decrease in responsiveness.

Well, an operating-system kernel is especially "a means to an end, and not an end unto itself." It's pretty much like any other application ... except that its purpose is to be a "system control program" (as IBM likes to refer to it), and that part or all of it necessarily remains resident in memory.

"Distro" writers can't predict what sort of hardware might be used to run their systems, but they do want it to run. Therefore, they necessarily include a lot of stuff in their kernels, necessarily compile them for more-generic CPU types, and also equip them with a pre-boot hardware detection and module-loading step (the so-called initrd). It is perceived that there is little cost in having "too much," as long as you have what you need. And, I think, that's probably a sound engineering decision.

You can greatly reduce the size of the system, if you want to. I have had ... (*sniff!* "I can't believe she's gone!" ... but, an image of her hard-drive lives on ...) a laptop, originally sold with Windows-95, running a completely-customized Gentoo distro (which distro is compiled entirely from source code), which frankly ran like a little bat out of Hell and at one point had an uptime of a year and a half. It started from cold in about four seconds flat, and was fully ready-to-go in about twenty seconds more. So, you can do it, if you want.

Microsoft Windows, remember, is in more-or-less an identical boat: unlike Apple, they don't know and can't predict exactly what hardware is going to be running their software. And, like a distro writer, they must be sure that the system "always starts up, gracefully and reasonably-quickly," on anything. (Distros like Knoppix, which are designed to run strictly from a DVD, i.e. for emergency repair purposes, are an even more extreme example.)

Thanks for the explanation. Sounds like what I want to do.

When I try to build a kernel the vast majority of kernel options in makeconfig aren't exactly apparent. You have to end up going with default settings otherwise the kernel isn't likely to work.

If you build a kernel for i386 or amd64 say, is that sufficient information for the platform or is it possible to tune the kernel for the respective platform even further?

I will first say that I do not claim to be an expert in kernels, Linux or Windows. I believe no one can ever be considered an expert in IT. We are always learning due to the simple fact that new technology is always being developed in all parts of the Information Technology field. Unless you are a leader of cutting edge technologies, to claim you are an expert suggests stagnancy, and that you have nothing more to learn.

There is a book called "The Linux Kernel In a Nutshell" that is quite good, though a bit outdated, in helping explain how to compile a custom kernel. It discusses how to identify hardware and how to tailor the kernel source to your specific hardware. For the most part if you replace the kernel version in the book with your desired kernel version, everything should work as expected.

I usually start with a basic kernel configuration using "make defconfig" and then edit it using "make menuconfig" to my liking. Once I have a working kernel configuration, I just patch the kernel source for each new update and run "make clean && make oldconfig" in the source directory. Then compile and profit. I have been able to build a quite small kernel using just the specific features required for my system using this process. Though for someone who has never done this, it can be daunting, requires research, and trial and error.

Sure if you build every option and feature in the kernel tree, you will have a bloated system. But this still doesn't mean that your system will run slower, the way Windows often does. The kernel will only load drivers and modules based on what hardware you are running. So if anything you are just using up extra disk space and increasing your boot time by a few seconds if you compile everything into your kernel.

Keep in mind though that drivers should be compiled as modules, not built in, if they are not required to boot. As the system boots, the kernel will load the modules required into memory to finish the boot process. The other modules installed in /lib/modules that do not pertain to your system, or to the software features on your system, will not be loaded into memory.

Kernels tend to follow hardware. If your system is slowing down simply by updates to kernel then there is something wrong or out of sync. You tend to want to keep kernel up to date for various reasons. Remember that your distro is a collection of kernel and many many applications and programs. And that distro's tend to provide a snapshot in time of current hardware and software and settings and parameters will match it more closely.

"Gentoo is an acquired taste," but I still like it a lot and still use it a lot. The Gentoo team has done a really, really nice job in ... shall we say ... "making Linux From Scratch (LFS) very palatable."

... and, by the way, if you have never done Linux From Scratch yet, you definitely should. Even though ... meh... "virtual machines make it much too easy." (koff, koff, wheeze, "these kids today ...")

Basically, what I did with my hardware was to boot Knoppix and observe what hardware drivers it selected and loaded. Then, when building my Gentoo (adapted from one of its stock configs ...), I selected only the drivers actually required by the motherboard, putting those into the kernel. Anything required by a removable device became a module. There was, therefore, no "initrd pre-boot" step at all. Both the kernel parameter and the corresponding Gentoo parameters were set for the actual CPU-type of the machine.

And, on the one hand, I had "the most economical kernel for that machine." But, on the other hand, the kernel was entirely specific to ... that machine. Which, of course, is the exact opposite of the goal that a distro-author is trying to achieve.

(And let it quickly and fairly be stated that Microsoft's engineers face the same challenge ... but on an even-grander scale since Windows is so much more than just "an operating system." It is "an operating environment." I think that we must give credit where credit is due: "their system may suck ... ... but they are good at what they do.")

And so, here's the sheer-beauty of Linux: you have a choice.

I got around to this and after 30 or so kernel builds, reduced its size from 178MB to 96MB.

I've noticed that there aren't that many options for the core kernel features. There's just a handful which are actually tunable. I was expecting more in the way of adjusting timing controls but you have to patch the source to do that.

The major parts of the kernel are in the drivers. It would be nice however to see a bit more categorization of the kernel drivers. Kernel drivers are absolutely crazy, you just have to follow any one of the Linux lists to see new stuff being generated everyday.

So after all this I'm left wanting of BSD. Only issue is poor video support and flaky wifi support. Also the Ports collections has been more problematic for me in terms of keeping track of dependencies where it usually tends to go all wrong sooner or later.

Hi,

I like to trim my kernels for custom installs. I find 'kernel parameters' are very valuable to me whenever initialization is important. Especially for my embedded work when working with hardware and space can be limited then a customized kernel can be very helpful. Look at the Linux Kernel section of Slackware®-Links More than just Slackware links for additional useful information!
Hope this helps.
Have fun & enjoy!

Or you could run a Freebsd kernel in Linux and see if you like it.

Something wrong there. Check the sizes again. Slackware comes with two kernels: huge at 6.1 MiB (approx. 6.5 MB), and generic at 3.3 MiB (approx. 3.5 MB).

I tried that once before and it failed. It was my understanding, that for a start, the disk had to have the XFS rather than ext4.

Yes just to clarify, that was referring to entire kernel package (incl. drivers & misc.)

The actual vmlinuz- is 3.0MB.

Frankly not much to tune in the core kernel.