Linux 4.12 Gained A Lot Of Weight: More Than One Million New Lines

[waxhead]

@Michael:
The article is a bit malformed: The preformatted text spreads over the column to the right. Perhaps the rest of the world have widescreen monitors and don't notice this. I on the other hand are still here with my 19" CRT from 1999 on 1280x1024 resolution.

[calc]

@Michael:
The article is a bit malformed: The preformatted text spreads over the column to the right. Perhaps the rest of the world have widescreen monitors and don't notice this. I on the other hand are still here with my 19" CRT from 1999 on 1280x1024 resolution.

Nope, its messed up even on a widescreen 1080p screen too. Even though there is lots of blankspace on each side of the main part of the website.

The webpage is hardcoded to 1150px wide.

[starshipeleven]

...as if x86-64 is the only platform that matters.

Well, that's the architecture he mentioned.
For other platforms it's better (or he is a noob at slimming down kernels). For example LEDE gets kernel images down to 1-1.5 MiB. Also because there it matters more (low flash space).

[Redfoxmoon]

Well, that's the architecture he mentioned.
For other platforms it's better (or he is a noob at slimming down kernels). For example LEDE gets kernel images down to 1-1.5 MiB. Also because there it matters more (low flash space).

It can shrink below 1 megabyte, if you *really* try with LEDE:-)

[Guest]

Indeed bloatware. Even an minimal Linux kernel is ridiculously big nowdays.
Most of the stuff end up in isolated drivers, but quite a lot end up in basic subsystem and core which all add up over time.
Even a completely naked x86-64 bzImage is on the 2M+ side.

What an irrelevant observation. Are you aware what even you are complaining about? Do you know compilers exists and have impact on kernel image size? Furthermore, compression etc.

[boxie]

Indeed bloatware. Even an minimal Linux kernel is ridiculously big nowdays.
Most of the stuff end up in isolated drivers, but quite a lot end up in basic subsystem and core which all add up over time.
Even a completely naked x86-64 bzImage is on the 2M+ side.

...and the half million lines of headers added will have exactly 0 impact on that image.

Linux has a lot of plumbing to make life easier for a lot of new things. Yes, it has a bunch of overhead - but that is not a bad thing.

It might not be the right choice for really resource limited hardware though, but luckily there are other things that be used instead

[milkylainen]

And that is an issue because?
Also "ridicolously big" is a very personal opinion there. It's not like there are x86-64 systems where that has any real impact.

Well. x86-64 was used as a reference since most people do have a grasp about it.
But size does not change much for arm, powerpc or for any other arch for that matter.
Since most of the code adding to minimal size is in core kernel and basic subsystems not arch.
Edit: Granted, modifications can get the size down. Both for memory subsystem efficiency and flash storage space on small machines.

[milkylainen]

What an irrelevant observation. Are you aware what even you are complaining about? Do you know compilers exists and have impact on kernel image size? Furthermore, compression etc.

You're the one being irrelevant. Code size sets are one thing and compilers something else. A compiler is not going to magically shrink stuff away.
Sure, you can optimize the code to small or use a thumb2 instruction set on an ARM kernel for example. But code size is there.
Compression is mostly done on the image not the runtime code which swells in RAM, affecting both caches, tlb's and memory.

[Guest]

You're the one being irrelevant. Code size sets are one thing and compilers something else. A compiler is not going to magically shrink stuff away.
Sure, you can optimize the code to small or use a thumb2 instruction set on an ARM kernel for example. But code size is there.
Compression is mostly done on the image not the runtime code which swells in RAM, affecting both caches, tlb's and memory.

You were judging by bzImage genius! Show me real memory usage.

[microcode]

Will 4.12 become an LTS release ?

Yeah, that's the first thing that came to mind for me. It stabilizes and irons out a lot of hardware support.

One thing which is missing is AMD's DC work, I hope they can finish that stuff up in the next cycle.