On Sat, 21 Nov 2015 02:00:33 +0100, Andi Kleen wrote: > > Sorry for the delay. > > On Mon, Nov 16, 2015 at 02:01:45PM +0100, Michal Marek wrote: > > Dne 15.11.2015 v 18:58 Andi Kleen napsal(a): > > > On Sun, Nov 15, 2015 at 11:27:05AM +1100, Stephen Rothwell wrote: > > >> Hi Michal, > > >> > > >> I notice that the kbuild tree (relative to Linus' tree) only contains > > >> lots of merges and these 2 commits from April 2014: > > > > > > Really should get in that patch officially. I have a variety of users. > > > And it clearly has been tested long enough in linux-next :) > > > Michal, enough to just repost it? > > > > So the commit in kbuild.git tree is identical to what is being tested > > out of tree? Could you nevertheless provide an updated changelog? One > > Yes. I'll provide a new ChangeLog. > > > (and actually only) of Linus' objections was that it was not clear at > > all what the actual benefits for the kernel itself are. Do you have some > > benchmarks perhaps, where LTO achieves a preformance gain? > > The main users use it to shrink the kernel. I'll run some new benchmarks. Yeah, people (especially Intel) seem eager to reduce any bits in kernel for IoT thingy, and LTO would help a lot in this regard. Many drivers have common helper functions and many of them are unused for a single driver. They can be dropped easily with LTO. Otherwise we'd end up having too many unmanageable Kconfigs. > > Also, did the > > compile time impact change with gcc 5.x? > > 5.x is better than 4.x but it's still a slower. It's also not incremential. At the last time I tested with the latest 5.x and stock binutils on openSUSE Tumbleweed, I failed to build, unfortunately. Partly the detection of gcc version doesn't work for 5.x, and partly something is missing in binutils side, although it's already built with plugin. I stopped at this point and didn't track further. Hopefully the requirement would become easier to manage in future if we merge this... thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
