Torvalds Is Unconvinced By LTO'ing A Linux Kernel
Phoronix: Torvalds Is Unconvined By LTO'ing A Linux Kernel
Yesterday patches were published via a pull request to enable experimental LTO support for the Linux 3.15 kernel, but Linus Torvalds hasn't yet decided whether he will accept this code in the upstream Linux kernel... Linus doesn't yet see the benefits in link-time optimizations for the kernel and isn't sure whether this code is ready yet to be mainlined...
This is a cool article
I hope it works on sparc32 despite being a less used architecture and sparc64 as well I'll be updating my kernel there soon as SMP support has been fixed (previously SMP kernels locked up on many UltraSparc boxes unless you forced them into uniprocessor mode)
Smaller kernels are really important for sparc32 as the kernel is at the point where you can't compile many drivers into the 3.4MB or so limit. Its around that anyway.. I think newer versions of SILO might have lifted that somewhat but I am not sure.
Smaller faster kernel why would ANYONE complain?
Last edited by cb88; 04-09-2014 at 04:35 AM.
Another good use case is embedded. Routers and small devices might have 2 to 64 MB of flash. Even with XZ compression modern Linux can be 3 MB on x86 with almost every feature disabled. Too bad Linus is such a douche and doesn't care about fighting bloat.
Originally Posted by cb88
sounds like we're going to see a ten page article full of benchmark graphs some time soon
thing is the code itself does not bring much to the footprint of a running kernel
Originally Posted by caligula
So someone has to make tests and benchamarks to evaluate its capabilities, problems and advantages.
I'm not sure I would want that thing in kernel just yet.
kernel is a thin layer of code anyway. There is not much potential for sizeable speed gains there, even if LTO would work much better than it does.
I've toyed with it and have seen many weird errors, so I recompiled everything with bog standard "-march=native -O2"
LTO is interesting as an idea, but with this gcc and binutils... no, thanks. I'll wait for next round of gcc before I try again.
And this goes even more for kernel. Having schisophrenic userland is bad enough, but stuffing that into kernel intself could be a disaster.
I think this is being missed in all the fuss. This is such a basic and simple step in getting software from 'hobby code' to 'production worthy'. Given the scope of the changes, everything needs to be fully tested, and changes on this scope and potential complexity should be fully justified with compelling arguments for rather than vague and rather hand-wavey "it does stuff quicker/smaller".
Originally Posted by Azrael5
Flash space, not the runtime footprint, is usually the problem in routers (which usually carry more RAM than Flash).
Originally Posted by gens