Re: [PATCH 03/13] jump label v9: x86 support

From: Ingo Molnar
Date: Thu Jun 10 2010 - 11:38:24 EST

* Andi Kleen <andi@xxxxxxxxxxxxxx> 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at