The Linux Kernel Continued Growing In 2016Q1: +500k L.O.C.

[phoronix]

Phoronix: The Linux Kernel Continued Growing In 2016Q1: +500k L.O.C.

With the first quarter being through at just around the time of the Linux 4.6 kernel merge window being done, I was curious to run some Git statistics on the Linux kernel code-base...

http://www.phoronix.com/scan.php?pag...rnel-Git-Stats

[dajomu]

I wonder, do the kernel developers have control of the kernel code? Can they easily see which code belongs to legacy hardware? How easy is it to remove unnecessary code which is only used for very specific hardware e.g. tablets, infotainment in cars, etc? Does it hurt performance in any way to have this big code base?

[Guest]

> I wonder, do the kernel developers have control of the kernel code?
Yes, but not the way you probably mean (whatever that is).


> Can they easily see which code belongs to legacy hardware?
There is no universal way to tell "this if switch can only trigger on 10 sparc computers", on the other hand if it is sparc specific, it's protected by sparc header guards which means that part of code won't compile for x86.

> How easy is it to remove unnecessary code which is only used for very specific hardware e.g. tablets, infotainment in cars, etc?
Depends. On the other hand, tablets and such use kernels with least ammount of weird hardware and generally have 4MB kernel images and no loadable modules.
This ties to previous/following question, since most x86 distributions use fairly slim core kernel image and have hundreds of megabytes of kernel code compiled into loadable kernel modules which are plugged in on demand (probe).

> Does it hurt performance in any way to have this big code base?
Size itself doesn't, size of things that actually run at your system increasing can slightly slow things down.

[caligula]

> How easy is it to remove unnecessary code which is only used for very specific hardware e.g. tablets, infotainment in cars, etc?
Depends. On the other hand, tablets and such use kernels with least ammount of weird hardware and generally have 4MB kernel images and no loadable modules.

Um, why would a larger kernel hurt that much on a tablet. They come with 64+ GB of storage these days. Just for the record, the operating system on my Windows tablet uses over 12 GB out of 64 GB and doesn't come with any 3rd party bloatware.

[caligula]

Maybe it is a time to configure and install a custom linux kernel from kernel.org. That will answer all your questionings, you will have faster boot and faster operating system. Google helps how to do a custom linux kernel.

The custom kernels are also growing few hundred kilobytes with every release. When I started with Linux 2.2, the kernel fit on a floppy. Now it's closer to 5 MB (with no modules) and it uses better compression (xz vs gzip/bzip).

[caligula]

When you match the custom kernel to your hardware, I doubt it will grow every stable release. When using make oldconfig, I have not seen so many new features that I would enable or are enabled by default. I started from 3.19.

It's just my impression. Of course the compressed executable grows a bit slower. For example 4.4 -> 4.5 increased one of my custom kernels 4 kilobytes (compressed) and the uncompressed vmlinux.bin was 47 kilobytes larger. I should have collected statistics. Maybe it's not too late now.

[verafox]

It's just my impression. Of course the compressed executable grows a bit slower. For example 4.4 -> 4.5 increased one of my custom kernels 4 kilobytes (compressed) and the uncompressed vmlinux.bin was 47 kilobytes larger. I should have collected statistics. Maybe it's not too late now.

This long post sounds like a rant, and it is. :-)
I started building my own kernels at 2.2 with Red Hat 6.2 circa 2000. (Yes, RedHat 6.2, not RHEL 6.)
The Red Hat kernel bzip2s were, IIRC, something like 1.2 MB.
I was proud to have my own under 900 KB.
Alas, I no longer have those, so cannot prove it anymore.

I never bothered with 2.4 at all because between the USB disaster (well, arguably the USB standard as whole IS a disaster, but I digress) and the VM disaster, it was clear no one had a clue.

Things settled a bit with 2.6, just in time for AMD64 to mature, so I went to that along with gentoo as a distribution (for the same reason --- AMD64 development was too new to trust to slovenly distros)..
At this point alot was already in place. amd64, SATA, USB2, Firewire, DVD filesystem, EXT3.
Sadly, roughly a year or so into that the 2.6 kernel developed crazy IO scheduler problems that persisted for years. Any heavy IO would kill interactivity. I believe that was the impetus for the multi queue idea, because it was clear no one in the kernel development team understood that problem either. Lots of talk about which IO scheduler was "best" (deadline, CFQ, whatever) but none could fix the issue.

I try my best to keep my kernels as lean as possible, and I'm all ears for improvements, but increasingly my efforts are being thwarted by both this new kernel bloat and also newfound userspace "requirements". (Those new things that always pop up in gentoo and complain that you don't have feature XYZ set in your kernel .config. Such as needing CONFIG_AUDIT_SYSCALL for consolekit, needing FUSE for truecrypt, needing TMPFS ACL for something else, etc.) Generally, I try to keep it down to Firewire (yes I require it), SATA for my chipsets, USB, use modules elsewhee as much as possible, etc. (I could go on a rant about consolekit, pam, udev, dbus, and all the other junk I never needed before...) And I have the Catalyst drivers, but a bunch of the earlier kernels also had "radeon" DRI compiled in by mistake.

So, on one system the bzip2s are this big:

1844222 Jan 30 2006 /boot/kernel-2.6.15.1
1833325 Jul 10 2006 /boot/kernel-2.6.17.4
1902314 Feb 2 2007 /boot/kernel-2.6.18.6n
2061232 Oct 24 2007 /boot/kernel-2.6.20.6n
2078750 Oct 25 2007 /boot/kernel-2.6.21.5n
2136616 Nov 2 2007 /boot/kernel-2.6.22.9n
2185624 Jan 4 2008 /boot/kernel-2.6.23.9n
2182232 Mar 23 2008 /boot/kernel-2.6.24.3n
2196984 Jun 7 2008 /boot/kernel-2.6.24.7n
2308256 May 10 2009 /boot/kernel-2.6.27.22
2393312 May 10 2009 /boot/kernel-2.6.28.9
2438848 May 15 2009 /boot/kernel-2.6.29.3
2427680 Oct 17 2009 /boot/kernel-2.6.30.3
2422416 Mar 28 2010 /boot/kernel-2.6.31.12
2443168 Jan 13 2010 /boot/kernel-2.6.31.6
2486576 Jun 5 2010 /boot/kernel-2.6.32.9
2417024 Oct 25 2010 /boot/kernel-2.6.34.5
2474464 Jan 31 2011 /boot/kernel-2.6.36.2
2475664 Apr 11 2011 /boot/kernel-2.6.36.4
2436416 Jul 19 2012 /boot/kernel-2.6.39.3

and on another system:

2305568 Sep 30 2009 kernel-2.6.30.3
2422784 Mar 27 2010 kernel-2.6.31.12
2328496 Jan 12 2010 kernel-2.6.31.6
2665376 Jan 30 2011 kernel-2.6.34.5
2450080 Jan 30 2011 kernel-2.6.36.2
2451248 Apr 6 2011 kernel-2.6.36.4
2444384 Apr 3 2012 kernel-2.6.39.3
2720688 Apr 8 2014 kernel-3.11.3
2792384 Jun 20 2014 kernel-3.14.8
2815920 Jun 27 2014 kernel-3.15.1
2842288 Oct 26 2014 kernel-3.17.1
2466272 Jul 19 2012 kernel-3.2.12
2532176 Nov 10 2012 kernel-3.4.9
2536432 Nov 17 2012 kernel-3.5.7
2542848 Feb 18 2013 kernel-3.6.11
2591376 Apr 16 2013 kernel-3.7.10
2641520 Oct 4 2013 kernel-3.8.13
3062016 Apr 3 07:58 kernel-4.5.0

.configs were tweaked a bunch over the years, compilers changed alot, but I think the overall trend is obvious. :-(
In 12 years since my first AMD64 system I've gained what?
1. Cleaner (smaller!) firewire code (the "juju" code)
2. SATA 2/3
3. multicore scheduler/NUMAish support
4. USB 3
5. driver modules for alot more stuff, like TV cards, but those are modules not listed in the numbers above
6. AMDGPU whenever they decide to abandon my cards. But still not compiled in my 4.5 kernel yet.
7. EXT4.
Most of that was also in place years ago already, too.
So you see why I'm never eager to jump to the latest kernel du jour anymore. Each one is just fatter.