Prev: [PATCH 1/4] TOMOYO: Add caller task's credential condition support.
Next: [PATCH 4/4] TOMOYO: Remove alias support.
From: Peter Zijlstra on 10 Jun 2010 10:20
On Thu, 2010-06-10 at 15:26 +0200, Andi Kleen wrote:
> The code generated by -Os is often terrible.

Is anybody on the gcc side of things looking into curing that?

I mean, what's the point of having an -Os if its useless in practise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 10 Jun 2010 10:30
On Thu, Jun 10, 2010 at 04:12:11PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-06-10 at 15:26 +0200, Andi Kleen wrote:
> > The code generated by -Os is often terrible.
>
> Is anybody on the gcc side of things looking into curing that?

The problem is that the smallest code is often terrible.
You could often be much better with spending a few more bytes.
But -Os means "smallest"

On the other hand -Os could be likely made smaller
(it often still is not very good), but I fear that would
make things even worse.

We probably would need a -Osmall-but-not-terrible or so,
but that's not there.
>
> I mean, what's the point of having an -Os if its useless in practise.

I think __hot / __cold but keeping the default at -O2 is a better
approach anyways. Hot paths should be -O2. It just needs some more work.

It already works for __init/__exit at least.

-Andi
--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jason Baron on 10 Jun 2010 11:10
On Thu, Jun 10, 2010 at 02:14:40PM +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz(a)infradead.org> wrote:
>
> > On Wed, 2010-06-09 at 17:39 -0400, Jason Baron wrote:
> > > + select HAVE_ARCH_JUMP_LABEL if !CC_OPTIMIZE_FOR_SIZE
> >
> > That deserves a comment somewhere, it basically makes OPTIMIZE_FOR_SIZE
> > useless...
>
> Hm, we need more than a comment for that - distros enable CC_OPTIMIZE_FOR_SIZE
> all the time, for the massive kernel image (and hotpath cache footprint)
> savings. Is this fixable?
>
> Thanks,
>
> Ingo
>

When I tested 'jump label' with CC_OPTIMIZE_FOR_SIZE, I saw a small
performance drop , b/c there is less block re-ordering happening. There
was a small gcc patch that Richard Henderson wrote to allow block
re-ordering while still taking size into account. However, it did
increase the text size somewhat from what current optimize for size
does. This small patch combined with jump labels resulted in the
expected performance gains. However, to keep the size to what it is now
a much more involved gcc patch would be required.

Thus, until this additional gcc optimization is done, I've posted this
as depends on !CC_OPTIMIZE_FOR_SIZE. If this gcc work is done, we can
lift this restriction. As mentioned, a number of large distros are
compiled !CC_OPTIMIZE_FOR_SIZE (rhel, sles), so we should still get a lot of
benefit from this. Also, if people find these patches useful we might
create some more impetus for the gcc work. So i see this as an iterative
thing.

thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mathieu Desnoyers on 10 Jun 2010 12:20
* Jason Baron (jbaron(a)redhat.com) wrote:
> On Thu, Jun 10, 2010 at 02:14:40PM +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz(a)infradead.org> wrote:
> >
> > > On Wed, 2010-06-09 at 17:39 -0400, Jason Baron wrote:
> > > > + select HAVE_ARCH_JUMP_LABEL if !CC_OPTIMIZE_FOR_SIZE
> > >
> > > That deserves a comment somewhere, it basically makes OPTIMIZE_FOR_SIZE
> > > useless...
> >
> > Hm, we need more than a comment for that - distros enable CC_OPTIMIZE_FOR_SIZE
> > all the time, for the massive kernel image (and hotpath cache footprint)
> > savings. Is this fixable?
> >
> > Thanks,
> >
> > Ingo
> >
>
> When I tested 'jump label' with CC_OPTIMIZE_FOR_SIZE, I saw a small
> performance drop , b/c there is less block re-ordering happening.

Is this a performance drop compared to a jump-label-less kernel or
compared to -O2 kernel compiled with jump labels ? Or both ?

Mathieu


--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Steven Rostedt on 10 Jun 2010 12:30
On Thu, 2010-06-10 at 15:26 +0200, Andi Kleen wrote:
> On Thu, Jun 10, 2010 at 02:14:40PM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra <peterz(a)infradead.org> wrote:
> >
> > > On Wed, 2010-06-09 at 17:39 -0400, Jason Baron wrote:
> > > > + select HAVE_ARCH_JUMP_LABEL if !CC_OPTIMIZE_FOR_SIZE
> > >
> > > That deserves a comment somewhere, it basically makes OPTIMIZE_FOR_SIZE
> > > useless...
> >
> > Hm, we need more than a comment for that - distros enable CC_OPTIMIZE_FOR_SIZE
> > all the time, for the massive kernel image (and hotpath cache footprint)
> > savings. Is this fixable?
>
> Actually the big distros (RHEL, SLES) disable it all the time now. It costs you
> in some benchmarks. The code generated by -Os is often terrible.
>
> Nearly everytime I investigate some bad asm code being generated by gcc
> it goes away when that flag is disabled.

I agree to the above statement. It was this option that first caused the
crazy mcount prefix code that totally broke the function tracer on i386.
With this option, some functions would send a copy of the return address
to mcount and not an actual pointer to the return address on stack. This
would confuse the function tracer and we ended up with a kernel panic.

-Os really needs to be fixed.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [PATCH 1/4] TOMOYO: Add caller task's credential condition support.
Next: [PATCH 4/4] TOMOYO: Remove alias support.