[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100610153742.GA9118@elte.hu>
Date: Thu, 10 Jun 2010 17:37:42 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andi Kleen <andi@...stfloor.org>
Cc: 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,
rostedt@...dmis.org, roland@...hat.com, rth@...hat.com,
mhiramat@...hat.com, fweisbec@...il.com, avi@...hat.com,
davem@...emloft.net, vgoyal@...hat.com, sam@...nborg.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 03/13] jump label v9: x86 support
* Andi Kleen <andi@...stfloor.org> wrote:
> > 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. [...]
Not all the big distros, Fedora certainly doesnt.
> [...] It costs you in some benchmarks. [...]
Microbenchmarks mostly, see below.
> The code generated by -Os is often terrible.
But it results in a kernel .text that is ~30% smaller, so considering the fact
that most real-life kernel code execution is instruction-cache-cold it's
generally a win.
But micro-benchmarks are instruction-cache-hot so that's where the pressure to
remove the flag comes from.
> Nearly everytime I investigate some bad asm code being generated by gcc it
> goes away when that flag is disabled.
That is not fixing anything, it is working bugs around.
> A much better to get smaller kernel images is to do more __cold annotations
> for slow paths. Newer gcc will then simply only do -Os for these functions.
That's an opt-in method and we cannot reach the kinds of 30% code size
reductions that -Os can achieve. Most code in the kernel is not cache-hot,
even on microbenchmarks.
A much better model would be to actively mark hot codepaths with a __hot
attribute instead. Then the code size difference can be considered on a case
by case basis.
And where GCC produces indefensibly crap code there GCC needs to be fixed.
Crap code often increases size so the fix would increase the efficiency of
-Os.
Thanks,
Ingo
--
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