* Markus Trippelsdorf wrote:
> On 2014.04.15 at 20:19 +0200, Sam Ravnborg wrote:
> > On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
> > > On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
> > > > >
> > > > > And while the code size reduction is less for MIPS than what
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.04.15 at 20:19 +0200, Sam Ravnborg wrote:
On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
And while the code size reduction is less for MIPS than
On 2014.04.15 at 20:19 +0200, Sam Ravnborg wrote:
> On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
> > On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
> > > >
> > > > And while the code size reduction is less for MIPS than what others have
> > > > reported for their
On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
> On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
> > >
> > > And while the code size reduction is less for MIPS than what others have
> > > reported for their platforms (I'm still investigating) is still is enough
> > > that
On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
> >
> > And while the code size reduction is less for MIPS than what others have
> > reported for their platforms (I'm still investigating) is still is enough
> > that embedded developers would commit murder for.
>
> I have experimented a little
>
> And while the code size reduction is less for MIPS than what others have
> reported for their platforms (I'm still investigating) is still is enough
> that embedded developers would commit murder for.
I have experimented a little with a patch that links all of vmlinux in one step.
I compared
On Mon, Apr 14, 2014 at 06:00:04PM -0700, Josh Triplett wrote:
> > and it slows down
> > kernel development'.
>
> No, it doesn't slow down development builds; it makes kernel builds
> slower if and only if LTO is turned on, which most kernel developers
> won't need to do. On the other hand,
* Josh Triplett wrote:
> > and it slows down kernel development'.
>
> No, it doesn't slow down development builds; it makes kernel builds
> slower if and only if LTO is turned on, which most kernel developers
> won't need to do.
>
> On the other hand, distro and embedded kernels can do so for
* Josh Triplett j...@joshtriplett.org wrote:
and it slows down kernel development'.
No, it doesn't slow down development builds; it makes kernel builds
slower if and only if LTO is turned on, which most kernel developers
won't need to do.
On the other hand, distro and embedded kernels
On Mon, Apr 14, 2014 at 06:00:04PM -0700, Josh Triplett wrote:
and it slows down
kernel development'.
No, it doesn't slow down development builds; it makes kernel builds
slower if and only if LTO is turned on, which most kernel developers
won't need to do. On the other hand, distro and
And while the code size reduction is less for MIPS than what others have
reported for their platforms (I'm still investigating) is still is enough
that embedded developers would commit murder for.
I have experimented a little with a patch that links all of vmlinux in one step.
I compared the
On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
And while the code size reduction is less for MIPS than what others have
reported for their platforms (I'm still investigating) is still is enough
that embedded developers would commit murder for.
I have experimented a little with a
On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
And while the code size reduction is less for MIPS than what others have
reported for their platforms (I'm still investigating) is still is enough
that embedded
On 2014.04.15 at 20:19 +0200, Sam Ravnborg wrote:
On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
And while the code size reduction is less for MIPS than what others have
reported for their platforms (I'm still
> > and it slows down
> > kernel development'.
>
> No, it doesn't slow down development builds; it makes kernel builds
> slower if and only if LTO is turned on, which most kernel developers
> won't need to do. On the other hand, distro and embedded kernels can do
> so for final builds, and
On Mon, Apr 14, 2014 at 12:32:05PM +0200, Ingo Molnar wrote:
>
> * Markus Trippelsdorf wrote:
>
> > On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
> > >
> > > * Andi Kleen wrote:
> > >
> > > > On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > > > > On Tue, Apr 8, 2014 at
* Markus Trippelsdorf wrote:
> On 2014.04.14 at 12:32 +0200, Ingo Molnar wrote:
> >
> > * Markus Trippelsdorf wrote:
> >
> > > On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
> > > >
> > > > * Andi Kleen wrote:
> > > >
> > > > > On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds
On 2014.04.14 at 12:32 +0200, Ingo Molnar wrote:
>
> * Markus Trippelsdorf wrote:
>
> > On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
> > >
> > > * Andi Kleen wrote:
> > >
> > > > On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > > > > On Tue, Apr 8, 2014 at 1:49 PM,
* Markus Trippelsdorf wrote:
> On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
> >
> > * Andi Kleen wrote:
> >
> > > On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > > > On Tue, Apr 8, 2014 at 1:49 PM, wrote:
> > > > >
> > > > > In addition to making the kernel smaller
On Mon, Apr 14, 2014 at 12:32:05PM +0200, Ingo Molnar wrote:
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
* Andi Kleen a...@linux.intel.com wrote:
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
On
and it slows down
kernel development'.
No, it doesn't slow down development builds; it makes kernel builds
slower if and only if LTO is turned on, which most kernel developers
won't need to do. On the other hand, distro and embedded kernels can do
so for final builds, and developers
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
* Andi Kleen a...@linux.intel.com wrote:
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
On Tue, Apr 8, 2014 at 1:49 PM, j...@joshtriplett.org wrote:
In
On 2014.04.14 at 12:32 +0200, Ingo Molnar wrote:
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
* Andi Kleen a...@linux.intel.com wrote:
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
On Tue, Apr 8,
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.04.14 at 12:32 +0200, Ingo Molnar wrote:
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
* Andi Kleen a...@linux.intel.com wrote:
On Tue, Apr 08, 2014
> 1) There was very little if any measurable LTO runtime speedup,
> despite agressive GCC options and despite user-space generally
> offering more optimizations opportunities than kernel space.
See Honza's email. There are lots of benefits in various
large projects.
Also BTW
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
>
> * Andi Kleen wrote:
>
> > On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > > On Tue, Apr 8, 2014 at 1:49 PM, wrote:
> > > >
> > > > In addition to making the kernel smaller and such (I'll leave the
> > > > specific stats
* Andi Kleen wrote:
> On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> > On Tue, Apr 8, 2014 at 1:49 PM, wrote:
> > >
> > > In addition to making the kernel smaller and such (I'll leave the
> > > specific stats there to Andi), here's the key awesomeness of LTO that
> > > you,
* Andi Kleen a...@linux.intel.com wrote:
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
On Tue, Apr 8, 2014 at 1:49 PM, j...@joshtriplett.org wrote:
In addition to making the kernel smaller and such (I'll leave the
specific stats there to Andi), here's the key
On 2014.04.09 at 08:01 +0200, Ingo Molnar wrote:
* Andi Kleen a...@linux.intel.com wrote:
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
On Tue, Apr 8, 2014 at 1:49 PM, j...@joshtriplett.org wrote:
In addition to making the kernel smaller and such (I'll leave
1) There was very little if any measurable LTO runtime speedup,
despite agressive GCC options and despite user-space generally
offering more optimizations opportunities than kernel space.
See Honza's email. There are lots of benefits in various
large projects.
Also BTW compiler
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
> On Tue, Apr 8, 2014 at 1:49 PM, wrote:
> >
> > In addition to making the kernel smaller and such (I'll leave the
> > specific stats there to Andi), here's the key awesomeness of LTO that
> > you, personally, should find useful and
Thanks Honza. Just one comment:
> The runtime benefits are more visible on bigger, bloated and less
> optimized projects than on hand tuned video encoder implementation.
> I believe Kernel largely falls into hand tuned category despite its size.
In my experience there's a lot of
> Hi Linus,
>
> > So right now, I see several reasons not to merge it ("It's so
> > experimental that we don't even want to encourage people to test it"
>
> I don't want them to enable it during allyesconfig because they
> might need more than 4GB of RAM to build it (especially with gcc
> 4.8,
FWIW, I'd really like to see this go in as an experimental feature.
Andi has already quoted my size results, which I thought were pretty
good, as well as given a pointer to my size optimization presentation.
Some of what follows is in the presentation, but here is a summary:
There are other
Hi Linus,
> So right now, I see several reasons not to merge it ("It's so
> experimental that we don't even want to encourage people to test it"
I don't want them to enable it during allyesconfig because they
might need more than 4GB of RAM to build it (especially with gcc
4.8, 4.9 is better).
On Tue, Apr 8, 2014 at 1:49 PM, wrote:
>
> In addition to making the kernel smaller and such (I'll leave the
> specific stats there to Andi), here's the key awesomeness of LTO that
> you, personally, should find useful and compelling: LTO will eliminate
> the need to add many lower-level Kconfig
On Tue, Apr 08, 2014 at 08:26:09AM -0700, Linus Torvalds wrote:
> On Mon, Apr 7, 2014 at 1:19 PM, Michal Marek wrote:
> > besides the kbuild branch, here is the LTO build support by Andi. It is
> > a separate branch, because it depends on other patches by Andi which
> > were merged through other
On Mon, Apr 7, 2014 at 1:19 PM, Michal Marek wrote:
>
> besides the kbuild branch, here is the LTO build support by Andi. It is
> a separate branch, because it depends on other patches by Andi which
> were merged through other trees. The link-time-optimization build is an
> experimental feature,
On Mon, Apr 7, 2014 at 1:19 PM, Michal Marek mma...@suse.cz wrote:
besides the kbuild branch, here is the LTO build support by Andi. It is
a separate branch, because it depends on other patches by Andi which
were merged through other trees. The link-time-optimization build is an
experimental
On Tue, Apr 08, 2014 at 08:26:09AM -0700, Linus Torvalds wrote:
On Mon, Apr 7, 2014 at 1:19 PM, Michal Marek mma...@suse.cz wrote:
besides the kbuild branch, here is the LTO build support by Andi. It is
a separate branch, because it depends on other patches by Andi which
were merged through
On Tue, Apr 8, 2014 at 1:49 PM, j...@joshtriplett.org wrote:
In addition to making the kernel smaller and such (I'll leave the
specific stats there to Andi), here's the key awesomeness of LTO that
you, personally, should find useful and compelling: LTO will eliminate
the need to add many
Hi Linus,
So right now, I see several reasons not to merge it (It's so
experimental that we don't even want to encourage people to test it
I don't want them to enable it during allyesconfig because they
might need more than 4GB of RAM to build it (especially with gcc
4.8, 4.9 is better). But
FWIW, I'd really like to see this go in as an experimental feature.
Andi has already quoted my size results, which I thought were pretty
good, as well as given a pointer to my size optimization presentation.
Some of what follows is in the presentation, but here is a summary:
There are other
Hi Linus,
So right now, I see several reasons not to merge it (It's so
experimental that we don't even want to encourage people to test it
I don't want them to enable it during allyesconfig because they
might need more than 4GB of RAM to build it (especially with gcc
4.8, 4.9 is
Thanks Honza. Just one comment:
The runtime benefits are more visible on bigger, bloated and less
optimized projects than on hand tuned video encoder implementation.
I believe Kernel largely falls into hand tuned category despite its size.
In my experience there's a lot of badly
On Tue, Apr 08, 2014 at 03:44:25PM -0700, Linus Torvalds wrote:
On Tue, Apr 8, 2014 at 1:49 PM, j...@joshtriplett.org wrote:
In addition to making the kernel smaller and such (I'll leave the
specific stats there to Andi), here's the key awesomeness of LTO that
you, personally, should
On Mon, Apr 07, 2014 at 10:19:19PM +0200, Michal Marek wrote:
> Hi Linus,
>
> besides the kbuild branch, here is the LTO build support by Andi. It is
> a separate branch, because it depends on other patches by Andi which
> were merged through other trees. The link-time-optimization build is an
>
Hi Linus,
besides the kbuild branch, here is the LTO build support by Andi. It is
a separate branch, because it depends on other patches by Andi which
were merged through other trees. The link-time-optimization build is an
experimental feature, so there one kconfig option to enable it and
another
Hi Linus,
besides the kbuild branch, here is the LTO build support by Andi. It is
a separate branch, because it depends on other patches by Andi which
were merged through other trees. The link-time-optimization build is an
experimental feature, so there one kconfig option to enable it and
another
On Mon, Apr 07, 2014 at 10:19:19PM +0200, Michal Marek wrote:
Hi Linus,
besides the kbuild branch, here is the LTO build support by Andi. It is
a separate branch, because it depends on other patches by Andi which
were merged through other trees. The link-time-optimization build is an
50 matches
Mail list logo
