Link-Time Optimization To Speed Up The Linux Kernel

[uid313]

I've seen 'inline' in there, at least.

inline is from C99 or C11 or from where?

Someone ought to run some automated analyzer tool that finds code that could be improved/refactored/rewritten to take advantage of modern features in C99 and C11.

[jrch2k8]

inline is from C99 or C11 or from where?

Someone ought to run some automated analyzer tool that finds code that could be improved/refactored/rewritten to take advantage of modern features in C99 and C11.

Kernels in general as massive and very dangerous beast to tame and normally is so close to the hardware that is hard to tell if any of this new techniques can even produce a performance improve after the shitstorm of patches, so this kinda things can take many many revisions to even get through and remember linux run in many architectures and 1 small change can break havoc in another architecture which make this changes slower since they need a truckload of testing and reviews.

things like LTO could be different since is a compiler feature [not a code change] that can provide some additional performance/size optimizations for almost free[wikipedia LTO is to extensive to explain here] but even so for this patch to reach mainline will need to support most architecture and probably several P1[google this one too] fixes in GCC in the next revisions

about compiling the kernel with microsoft c compiler, errhmm, never will ever happen and msvc isn't exactly a performance king either[including C++] that is why ICC and PGC are so common on HPC industry to start with

about llvm forget about it in the next 5 years at minimal, linus won't allow anything upstream that can't produce code for all the kernel supported plataforms and provide ultra uber massively performance/size improvements to justify the change and llvm can't compete with GCC in neither for now. So if you wanna llvm/whatever compiler/etc. make a git repo and do it yourself so ppl can download your patches and test[someone did this with ICC some time ago] but even so it would be a very hard task to get them upstream, if you feel like loling and asking why?? well start to create those patches and you will see the light

[elanthis]

inline is from C99 or C11 or from where?

http://en.wikipedia.org/wiki/C99 <-- inline keyword
http://en.wikipedia.org/wiki/C11_(C_standard_revision)

[frantaylor]

linus won't allow anything upstream

Android will probably never, ever, ship with a stock linux kernel.

Neither will RHEL or any other "supported" distribution.

So what?

The opinions of Linus have not, and are not even slowing down, development of features that people want.

This is why we have GPL, so we don't have to worry about his opinions, even though he holds the copyright.

If RedHat or google or anyone else finds value in this, they will scoop it right up regardless, good for them.

MIS everywhere is looking for reasons to throw out their Windows servers. We've been putting up with remote management nightmares* for just far too long. Between the nightmare of Windows 8 and a nice uptick in linux kernel performance, there's more reason for RHEL migration.

To me this is a very exciting thing, you don't see significant overall kernel performance improvements very often.

* - from over a DSL connection, try running multiple Remote Desktop connections, and then try the same with SSH connections.

[ciplogic]

LTO does not speed up, or if it does it, it will do it with a minimal ratio: the hand-tuned performance codebases have little to no speedup, and this was written into the LTO based papers. LTO gives more inline strategies, and it can reduce/remove the small functions. As there is no profiling inside LTO, the inlining are mostly based on space and remove dead code, which in turn creates smaller binaries.
LTO most likely will reduce the kernel size by a factor of 5 to 10%.
If a distribution wants to try, it can use a higher optimization level (like -O3) to get better performance at the price of a bigger binary size and will use LTO to reduce back the size to the original with lower optimizations.

[curaga]

Cache effects, man, cache effects. They're all the more effective in a kernel.

[jrch2k8]

Android will probably never, ever, ship with a stock linux kernel.

Neither will RHEL or any other "supported" distribution.

So what?

The opinions of Linus have not, and are not even slowing down, development of features that people want.

This is why we have GPL, so we don't have to worry about his opinions, even though he holds the copyright.

If RedHat or google or anyone else finds value in this, they will scoop it right up regardless, good for them.

MIS everywhere is looking for reasons to throw out their Windows servers. We've been putting up with remote management nightmares* for just far too long. Between the nightmare of Windows 8 and a nice uptick in linux kernel performance, there's more reason for RHEL migration.

To me this is a very exciting thing, you don't see significant overall kernel performance improvements very often.

* - from over a DSL connection, try running multiple Remote Desktop connections, and then try the same with SSH connections.

you are wrong.

1.) android is really trying to ship with a vanilla kernel from some time now, they are sending their custom patches to upstream because the current model is a nightmare from the maintenance POV, just imagine in 1 year or 6 months they have to support ARM64 for the next gen phones/tablets but the code is written for kernel 3.7[most likely] but their working kernel is still in the 2.6 tree <--- pure hardcore pain

2.) redhat ship a vanilla kernel[i would like to see where you get this from LOL], you can check so in the rpm source package and the fact that they may need sometimes to patch or backport features from higher or lower versions of the vanilla sources doesn't mean redhat ship an custom kernel it just mean they need to keepalive some feature to stay abi compatible or that a common hardware driver got important fixes in later revisions[99% of the time] but even so they upload most of those patches back to upstream [check the kernel git and count the redhat commits]

3.) the same apply to all distros, they don't ship custom kernel they ship vanilla with handpicked backports[or like some ubuntu versions messy ugly hacks]

4.) linus is not irrelevant, if a patch is not accepted upstream it will suffer a slow death that is a fact because is just too hard to keep the code synced with upstream and since the crowd that can compile their kernel with this out of tree patch are too small for bothering in keeping the code alive in the long run

5.) GPL don't state that your patch has to be accepted it just means you can take the code and do whatever you want [as long as you follow the license conditions] hence if linus says no your project has to live as an out of tree patch until you get bored.

6.) ok if your patch is rejected once but later in time meet the conditions to enter upstream linus will acept it or at least propose a technical review of the patches[this is the common case] so once llvm can support the same number of architectures that gcc do and prove to provide an important enhacement with no regressions then we can talk about llvm and the kernel

7.) about C99 no one is saying it won't help, im saying many of those features could be useful but a kernel is not your average binary and the code is pretty close to baremetal[and a ton of ASM btw], meaning that maybe this feature won't provide enough punch to justify all the work, so someone has to take this job out of tree and test like hell and determine if this is FUD or it will save kittens and puppies[scientific method > whining cuz i want a feature because sounds cool]

8.) not just redhat or google but everyone is free to clone the kernel git tree and experiment to their heart content with it and if your experimentation produce tangible results then you send your patches to be included in the main tree so all can benefit[OSS always work like this since i remember] so i don't get your point?

9.) as far as i know linus own the name Linux but the copyright is from every developer not linus[again would be nice post a link] hence why he has stated many times that is almost impossible to change linux license since every developer that has a patch in the kernel has to approve the change and the problem is that many died and thier code has to be rewritten from scratch, bla bla bla[google it im not a lawyer so best to read from someone else]

10.) you can use ssh on windows/mac but ok i admit is better than RDP

11.) "The opinions of Linus have not, and are not even slowing down, development of features that people want." linus don't give a rat ass about what user wants since he is smart enough to understand they are almost always wrong so as an outstanding engineer[like most of the core devs] the features to be included has to meet the engienerring specs and pass a technical board review and that is the way it should be like it or not. this is science not a popularity pageant and in the case of kon kolivas[i bet you are gonna lol me with this one] i think linus[and core devs] had good reason to reject many of those patches and i have to admit the code was very very complex compared to cfq[which introduce the maintenance variable]

[russofris]

@fran & jrc

I believe you are both correct.

I do not believe an android device will ever 'ship' with the vanilla kernel.
I do believe that android features (wakelocks) will make it back into mainline eventually.
By the time that they do, android will likely have new features that will trickle down into mainline, eventually.

This ins't to say that mainline is in a perpetual state of catching up, it is saying that features often need an additional period of vetting and re-thinking before being placed in mainline. This is probably a good thing. As long as mainline remains the foundation upon which everything is built, and projects like andriod rebase frequently enough, we're all set.

F

[TAXI]

I wonder how many guys here know that android wanted to ship with the vanilla kernel, but their patches where rejected upstream so they where forced to fork the kernel...

[russofris]

I wonder how many guys here know that android wanted to ship with the vanilla kernel, but their patches where rejected upstream so they where forced to fork the kernel...

Pretty much all of us do. It's good that they wanted to ship vanilla. It's good that the patches were rejected (they were fugly). It's good that they forked to meet a timeline. It's good that some of the patches and features have been reworked and integrated into mainline. It's good that Android developers and the community are working to bring Android closer to mainline.

The benefit of Android's fork was that they could release the features "right now" back in 2006-ish, and not wait for the community vetting process. It possibly could have been handled a bit more gracefully back then, if not technically, then socially. I think everyone was terribly nervous about the situation, but it doesn't appear to be that bad now. The linux kernel, and android, have improved significantly as a result of Google's efforts.

<sneer>Where's your messiah now?</sneer>

F