lkml.org 
[lkml]   [2011]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] x86: page: get_order() optimization

* Maksym Planeta <mcsim.planeta@gmail.com> wrote:

> On Sat, 27/03/2011 at 13:33 +0200, Ingo Molnar wrote:
> > Just wondering, what's the before/after 'size vmlinux' effect on a 'make
> > defconfig' x86 kernel? Does the optimization make the kernel smaller as well,
> > besides making it faster?
>
> Thank you for advice. I didn't really mentioned it. So without my patch:
>
> size vmlinux
> text data bss dec hex filename
> 7915025 1253060 1122304 10290389 9d04d5 vmlinux
>
> And with it:
>
> size vmlinux
> text data bss dec hex filename
> 7919150 1251364 1122304 10292818 9d0e52 vmlinux
>
> Size increased. But I discovered that if I replace "inline" with
> "__always_inline" in get_order(), size will be following:
>
> size vmlinux
> text data bss dec hex filename
> 7914481 1249252 1122304 10286037 9cf3d5 vmlinux
>
> And this is less than with same modification in asm-general:
>
> size vmlinux
> text data bss dec hex filename
> 7914713 1249268 1122304 10286285 9cf4cd vmlinux
>
> With my patch and "__always_inline" instead of just "inline" size will
> be the smallest.

Weird, that's an unexpected resut.

Have you looked at the disassembly, why does the size increase? I'd expect such
a straight assembly optimization to result in smaller code: in the non-constant
case it should be the same size as before, in the constant case it should be
smaller, because BSR should be smaller than an open-coded search loop, right?

One sidenote, defconfig turns these on:

CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_OPTIMIZE_INLINING=y

And some versions of GCC arent very good with these.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-03-28 07:11    [W:0.233 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site