lkml.org 
[lkml]   [2010]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 03/13] jump label v9: x86 support

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


\
 
 \ /
  Last update: 2010-06-10 17:41    [W:0.107 / U:4.772 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site