Re: linux-next: clean up the kbuild tree?

From: Takashi Iwai <tiwai@suse.de>
To: Andi Kleen <ak@linux.intel.com>
Cc: Michal Marek <mmarek@suse.cz>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-next: clean up the kbuild tree?
Date: Sat, 21 Nov 2015 11:55:39 +0100	[thread overview]
Message-ID: <s5h4mgfzkno.wl-tiwai@suse.de> (raw)
In-Reply-To: <20151121010033.GB8438@tassilo.jf.intel.com>

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