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

[Ingo Molnar]

* 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 
-Os.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/