[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1276187351.12038.24.camel@gandalf.stny.rr.com>
Date: Thu, 10 Jun 2010 12:29:11 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Andi Kleen <andi@...stfloor.org>
Cc: Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
Jason Baron <jbaron@...hat.com>, linux-kernel@...r.kernel.org,
mathieu.desnoyers@...ymtl.ca, hpa@...or.com, tglx@...utronix.de,
roland@...hat.com, rth@...hat.com, mhiramat@...hat.com,
fweisbec@...il.com, avi@...hat.com, davem@...emloft.net,
vgoyal@...hat.com, sam@...nborg.org
Subject: Re: [PATCH 03/13] jump label v9: x86 support
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@...radead.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists