* Josh Triplett wrote:
> > > Also, you've only applied these to 64-bit; could you please
> > > apply them to both 32-bit and 64-bit, since many embedded
> > > systems aiming for small code size use 32-bit? (Unless 32-bit
> > > already defaults to these.)
> >
> > First things first - 64-bit
* Josh Triplett j...@joshtriplett.org wrote:
Also, you've only applied these to 64-bit; could you please
apply them to both 32-bit and 64-bit, since many embedded
systems aiming for small code size use 32-bit? (Unless 32-bit
already defaults to these.)
First things first -
On Sun, May 17, 2015 at 07:34:29AM +0200, Ingo Molnar wrote:
>
> * Josh Triplett wrote:
>
> > On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
> > > * Denys Vlasenko wrote:
> > > > > What do you guys think about this? I think we should seriously
> > > > > consider relaxing our
On Sun, May 17, 2015 at 07:34:29AM +0200, Ingo Molnar wrote:
* Josh Triplett j...@joshtriplett.org wrote:
On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
What do you guys think about this? I think we should seriously
* Josh Triplett wrote:
> On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
> > * Denys Vlasenko wrote:
> > > > What do you guys think about this? I think we should seriously
> > > > consider relaxing our alignment defaults.
> > >
> > > Looks like nobody objected. I think it's ok
* Josh Triplett j...@joshtriplett.org wrote:
On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
What do you guys think about this? I think we should seriously
consider relaxing our alignment defaults.
Looks like nobody
On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
> * Denys Vlasenko wrote:
> > > What do you guys think about this? I think we should seriously
> > > consider relaxing our alignment defaults.
> >
> > Looks like nobody objected. I think it's ok to submit
> > this patch for real.
>
>
On Mon, Sep 17, 2001 at 07:00:00AM +, Ingo Molnar wrote:
* Denys Vlasenko dvlas...@redhat.com wrote:
What do you guys think about this? I think we should seriously
consider relaxing our alignment defaults.
Looks like nobody objected. I think it's ok to submit
this patch for
* Denys Vlasenko wrote:
> On 05/14/2015 08:17 PM, Ingo Molnar wrote:
> > There were also these other changes I tested:
> >
> > +# Reduces vmlinux size by 0.25%:
> > +KBUILD_CFLAGS += -fno-caller-saves
> > +
> > +# Reduces vmlinux size by 1.10%:
> > +
On 05/14/2015 08:17 PM, Ingo Molnar wrote:
> There were also these other changes I tested:
>
> +# Reduces vmlinux size by 0.25%:
> +KBUILD_CFLAGS += -fno-caller-saves
> +
> +# Reduces vmlinux size by 1.10%:
> +KBUILD_CFLAGS += -fno-inline-small-functions
> +
> +
* Denys Vlasenko wrote:
> > What do you guys think about this? I think we should seriously
> > consider relaxing our alignment defaults.
>
> Looks like nobody objected. I think it's ok to submit
> this patch for real.
Yeah, so my plan is to apply the following three changes from that
On 04/10/2015 02:08 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> So restructure the loop a bit, to get much tighter code:
>>
>> 0030 :
>> 30:55 push %rbp
>> 31:65 48 8b 14 25 00 00mov%gs:0x0,%rdx
>> 38:00 00
>>
On 04/10/2015 02:08 PM, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
So restructure the loop a bit, to get much tighter code:
0030 mutex_spin_on_owner.isra.5:
30:55 push %rbp
31:65 48 8b 14 25 00 00mov%gs:0x0,%rdx
* Denys Vlasenko dvlas...@redhat.com wrote:
What do you guys think about this? I think we should seriously
consider relaxing our alignment defaults.
Looks like nobody objected. I think it's ok to submit
this patch for real.
Yeah, so my plan is to apply the following three changes from
* Denys Vlasenko dvlas...@redhat.com wrote:
On 05/14/2015 08:17 PM, Ingo Molnar wrote:
There were also these other changes I tested:
+# Reduces vmlinux size by 0.25%:
+KBUILD_CFLAGS += -fno-caller-saves
+
+# Reduces vmlinux size by 1.10%:
+
On 05/14/2015 08:17 PM, Ingo Molnar wrote:
There were also these other changes I tested:
+# Reduces vmlinux size by 0.25%:
+KBUILD_CFLAGS += -fno-caller-saves
+
+# Reduces vmlinux size by 1.10%:
+KBUILD_CFLAGS += -fno-inline-small-functions
+
+#
* Markus Trippelsdorf wrote:
> > I'm not so sure about that one, our data access patterns are
> > usually a lot more well thought out than our code alignment (which
> > is really mostly compiler controlled). It also gives limited
> > savings:
> >
> > 9202488 vmlinux gcc-5
> > 9186105
On 2015.04.14 at 11:16 +0200, Ingo Molnar wrote:
>
> * Markus Trippelsdorf wrote:
>
> > On 2015.04.14 at 07:38 +0200, Ingo Molnar wrote:
> > >
> > > Just to make sure, could you please also apply the 3 alignment patches
> > > attached below? There's a lot of noise from extra alignment.
> >
>
* Markus Trippelsdorf wrote:
> On 2015.04.14 at 07:38 +0200, Ingo Molnar wrote:
> >
> > Just to make sure, could you please also apply the 3 alignment patches
> > attached below? There's a lot of noise from extra alignment.
>
> Here's an updated table:
>
>textdata bss dec
On 2015.04.14 at 07:38 +0200, Ingo Molnar wrote:
>
> Just to make sure, could you please also apply the 3 alignment patches
> attached below? There's a lot of noise from extra alignment.
Here's an updated table:
textdata bss dec filename
8746230 970072 802816 10519118
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2015.04.14 at 07:38 +0200, Ingo Molnar wrote:
Just to make sure, could you please also apply the 3 alignment patches
attached below? There's a lot of noise from extra alignment.
Here's an updated table:
textdata bss
On 2015.04.14 at 07:38 +0200, Ingo Molnar wrote:
Just to make sure, could you please also apply the 3 alignment patches
attached below? There's a lot of noise from extra alignment.
Here's an updated table:
textdata bss dec filename
8746230 970072 802816 10519118
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
I'm not so sure about that one, our data access patterns are
usually a lot more well thought out than our code alignment (which
is really mostly compiler controlled). It also gives limited
savings:
9202488 vmlinux gcc-5
On 2015.04.14 at 11:16 +0200, Ingo Molnar wrote:
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2015.04.14 at 07:38 +0200, Ingo Molnar wrote:
Just to make sure, could you please also apply the 3 alignment patches
attached below? There's a lot of noise from extra
* Markus Trippelsdorf wrote:
> On 2015.04.13 at 11:31 -0700, Linus Torvalds wrote:
> > On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
> > wrote:
> > >
> > > I must have made a measurement mistake above, because the actual code
> > > size savings are roughly 5%:
> >
> > Can you check
On 2015.04.13 at 11:31 -0700, Linus Torvalds wrote:
> On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
> wrote:
> >
> > I must have made a measurement mistake above, because the actual code
> > size savings are roughly 5%:
>
> Can you check against the -fno-guess-branch-probability output?
On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
wrote:
>
> I must have made a measurement mistake above, because the actual code
> size savings are roughly 5%:
Can you check against the -fno-guess-branch-probability output?
Does lto (without pgo) perhaps end up undoing a lot of the random
On 2015.04.13 at 18:23 +0200, Markus Trippelsdorf wrote:
> On 2015.04.12 at 12:14 +0200, Ingo Molnar wrote:
> > In my (past) experience the main win from -flto is not due to better
> > hot/cold decisions, but simply due to more aggressive dead code
> > elimination. -flto has less of an effect on
On 2015.04.12 at 12:14 +0200, Ingo Molnar wrote:
> In my (past) experience the main win from -flto is not due to better
> hot/cold decisions, but simply due to more aggressive dead code
> elimination. -flto has less of an effect on code that is actually
> being executed.
>
> Which isn't to be
On 2015.04.13 at 11:31 -0700, Linus Torvalds wrote:
On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
I must have made a measurement mistake above, because the actual code
size savings are roughly 5%:
Can you check against the
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2015.04.13 at 11:31 -0700, Linus Torvalds wrote:
On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
I must have made a measurement mistake above, because the actual code
size savings are roughly
On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
I must have made a measurement mistake above, because the actual code
size savings are roughly 5%:
Can you check against the -fno-guess-branch-probability output?
Does lto (without pgo) perhaps end up undoing
On 2015.04.13 at 18:23 +0200, Markus Trippelsdorf wrote:
On 2015.04.12 at 12:14 +0200, Ingo Molnar wrote:
In my (past) experience the main win from -flto is not due to better
hot/cold decisions, but simply due to more aggressive dead code
elimination. -flto has less of an effect on code
On 2015.04.12 at 12:14 +0200, Ingo Molnar wrote:
In my (past) experience the main win from -flto is not due to better
hot/cold decisions, but simply due to more aggressive dead code
elimination. -flto has less of an effect on code that is actually
being executed.
Which isn't to be
On Fri, 10 Apr 2015, Linus Torvalds wrote:
> It turns out that gcc's -Os is just horrible nasty crap. It doesn't
> actually make good tradeoffs for code density, because it doesn't make
> any tradeoffs at all. It tries to choose small code, even when it's
> ridiculously bad small code.
>
> For
* Markus Trippelsdorf wrote:
> On 2015.04.10 at 06:18 -0700, H. Peter Anvin wrote:
> > On 04/10/2015 05:50 AM, Denys Vlasenko wrote:
> > >
> > > However, I'm an -Os guy. Expect -O2 people to disagree :)
> > >
> >
> > The problem with -Os is that the compiler will make *any* tradeoffs to
> >
On Fri, 10 Apr 2015, Linus Torvalds wrote:
It turns out that gcc's -Os is just horrible nasty crap. It doesn't
actually make good tradeoffs for code density, because it doesn't make
any tradeoffs at all. It tries to choose small code, even when it's
ridiculously bad small code.
For
* Markus Trippelsdorf mar...@trippelsdorf.de wrote:
On 2015.04.10 at 06:18 -0700, H. Peter Anvin wrote:
On 04/10/2015 05:50 AM, Denys Vlasenko wrote:
However, I'm an -Os guy. Expect -O2 people to disagree :)
The problem with -Os is that the compiler will make *any* tradeoffs
On 2015.04.10 at 06:18 -0700, H. Peter Anvin wrote:
> On 04/10/2015 05:50 AM, Denys Vlasenko wrote:
> >
> > However, I'm an -Os guy. Expect -O2 people to disagree :)
> >
>
> The problem with -Os is that the compiler will make *any* tradeoffs to
> save a byte. It is really designed to squeeze
On Fri, Apr 10, 2015 at 07:10:08AM -0700, Paul E. McKenney wrote:
> On Fri, Apr 10, 2015 at 02:08:46PM +0200, Ingo Molnar wrote:
> > * Ingo Molnar wrote:
[...]
> > Btw., totally off topic, the following NOP caught my attention:
> >
> > > 5a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
On 2015.04.10 at 14:50 +0200, Denys Vlasenko wrote:
> New-ish versions of gcc allow people to specify optimization
> options per function:
>
> https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
>
> optimize
> The optimize attribute is used to specify that a
On 2015.04.10 at 14:50 +0200, Denys Vlasenko wrote:
New-ish versions of gcc allow people to specify optimization
options per function:
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
optimize
The optimize attribute is used to specify that a function is
On Fri, Apr 10, 2015 at 07:10:08AM -0700, Paul E. McKenney wrote:
On Fri, Apr 10, 2015 at 02:08:46PM +0200, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
[...]
Btw., totally off topic, the following NOP caught my attention:
5a: 66 0f 1f 44 00 00 nopw
On 2015.04.10 at 06:18 -0700, H. Peter Anvin wrote:
On 04/10/2015 05:50 AM, Denys Vlasenko wrote:
However, I'm an -Os guy. Expect -O2 people to disagree :)
The problem with -Os is that the compiler will make *any* tradeoffs to
save a byte. It is really designed to squeeze as much
On Fri, Apr 10, 2015 at 05:54:10PM +0200, Borislav Petkov wrote:
> On Fri, Apr 10, 2015 at 05:48:51PM +0200, Denys Vlasenko wrote:
> > As you know, manuals are not be-all, end-all documents.
> > They contains mistakes. And they are written before silicon
> > is finalized, and sometimes they
On Fri, Apr 10, 2015 at 05:54:10PM +0200, Borislav Petkov wrote:
On Fri, Apr 10, 2015 at 05:48:51PM +0200, Denys Vlasenko wrote:
As you know, manuals are not be-all, end-all documents.
They contains mistakes. And they are written before silicon
is finalized, and sometimes they advertise
46 matches
Mail list logo
