All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maksym Planeta <mcsim.planeta@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: mingo@redhat.com, kernel-janitors@vger.kernel.org,
	namhyung@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86: page: get_order() optimization
Date: Sun, 27 Mar 2011 17:15:36 +0000	[thread overview]
Message-ID: <1301246136.2291.49.camel@debian> (raw)
In-Reply-To: <20110327113323.GA27825@elte.hu>

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.

Signed-off-by: Maksym Planeta <mcsim.planeta@gmail.com>
---
 arch/x86/include/asm/getorder.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/getorder.h
b/arch/x86/include/asm/getorder.h
index b0c6f57..6220783 100644
--- a/arch/x86/include/asm/getorder.h
+++ b/arch/x86/include/asm/getorder.h
@@ -27,7 +27,7 @@ static __always_inline int __get_order(unsigned long
size)
 }
 
 /* Pure 2^n version of get_order */
-static inline __attribute_const__  int get_order(unsigned long size)
+static __always_inline __attribute_const__  int get_order(unsigned long
size)
 {
	int order;
-- 
Thanks,

Maksym Planeta


WARNING: multiple messages have this Message-ID (diff)
From: Maksym Planeta <mcsim.planeta@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: mingo@redhat.com, kernel-janitors@vger.kernel.org,
	namhyung@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86: page: get_order() optimization
Date: Sun, 27 Mar 2011 20:15:36 +0300	[thread overview]
Message-ID: <1301246136.2291.49.camel@debian> (raw)
In-Reply-To: <20110327113323.GA27825@elte.hu>

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.

Signed-off-by: Maksym Planeta <mcsim.planeta@gmail.com>
---
 arch/x86/include/asm/getorder.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/getorder.h
b/arch/x86/include/asm/getorder.h
index b0c6f57..6220783 100644
--- a/arch/x86/include/asm/getorder.h
+++ b/arch/x86/include/asm/getorder.h
@@ -27,7 +27,7 @@ static __always_inline int __get_order(unsigned long
size)
 }
 
 /* Pure 2^n version of get_order */
-static inline __attribute_const__  int get_order(unsigned long size)
+static __always_inline __attribute_const__  int get_order(unsigned long
size)
 {
	int order;
-- 
Thanks,

Maksym Planeta


  parent reply	other threads:[~2011-03-27 17:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-27  8:45 [PATCH v2] x86: page: get_order() optimization Maksym Planeta
2011-03-27  8:45 ` Maksym Planeta
2011-03-27 11:33 ` Ingo Molnar
2011-03-27 11:33   ` Ingo Molnar
2011-03-27 16:22   ` Peter Hüwe
2011-03-27 16:22     ` Peter Hüwe
2011-03-27 17:15   ` Maksym Planeta [this message]
2011-03-27 17:15     ` Maksym Planeta
2011-03-28  5:08     ` Ingo Molnar
2011-03-28  5:08       ` Ingo Molnar
2011-03-28 19:33       ` Maksym Planeta
2011-03-28 19:33         ` Maksym Planeta
2011-03-28 19:44         ` H. Peter Anvin
2011-03-28 19:44           ` H. Peter Anvin
2011-04-01 14:08           ` Maksym Planeta
2011-04-01 14:08             ` Maksym Planeta
2011-03-28 19:47 ` H. Peter Anvin
2011-03-28 19:47   ` H. Peter Anvin
2011-03-29  7:27   ` Ingo Molnar
2011-03-29  7:27     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1301246136.2291.49.camel@debian \
    --to=mcsim.planeta@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=namhyung@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.