All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Robert Richter <robert.richter@amd.com>
Subject: Re: [PATCH] ring_buffer: fix ring_buffer_event_length()
Date: Thu, 8 Jan 2009 11:26:28 -0800	[thread overview]
Message-ID: <20090108112628.aa48a3f9.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090108115530.GA1539@elte.hu>

On Thu, 8 Jan 2009 12:55:30 +0100 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Wed, 7 Jan 2009 23:58:39 -0500 (EST) Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > >  kernel/trace/ring_buffer.c |    8 +++++++-
> > 
> > <looks>
> > 
> > heavens, what a lot of inlining.  Looks like something from 1997 :)
> > 
> > Prove me wrong!
> > 
> > 
> > From: Andrew Morton <akpm@linux-foundation.org>
> > 
> >           text    data     bss     dec     hex filename
> > before:  11320     228       8   11556    2d24 kernel/trace/ring_buffer.o
> > after:   10592     228       8   10828    2a4c kernel/trace/ring_buffer.o
> 
> You are wrong :-)

Not.

> With x86 defconfig and gcc 4.3.2 i get zero change in size:

With my config and my gcc I see a large change in size.  So those
`inline' statements in that C file are *wrong*.

>   kernel/trace/ring_buffer.o:
> 
>      text	   data	    bss	    dec	    hex	filename
>     11485	    228	      8	  11721	   2dc9	ring_buffer.o.before
>     11485	    228	      8	  11721	   2dc9	ring_buffer.o.after
> 
>   md5:
>      55447563cd459bbb02c6234b2544fcc2  ring_buffer.o.before.asm
>      55447563cd459bbb02c6234b2544fcc2  ring_buffer.o.after.asm
> 
> (i took out the free_page() bit to only measure the inlining)
> 
> That is the same with and without CONFIG_OPTIMIZE_INLINING - i.e. recent 
> GCC gets the inlining right.
> 
> Really, we should stop bothering about inlines on the source code level 
> (the kernel has 20,000 inlines and around 100,000 functions - do we really 
> want to maintain inlining information on a per function basis?) - and we 
> should tell the GCC folks when the compiler messes up some detail.
> 
> Or if GCC messes up inlining so much in the future that we cannot live 
> with it, we can go back to "always inline" and manual annotations again. 
> Or write a new compiler. (the latter is probably less work ;-)

None of that makes the inline statements in ring_buffer.c less wrong. 
It says that with some configs and some gcc versions, their damage is
lessened.


  reply	other threads:[~2009-01-08 19:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08  4:58 [PATCH] ring_buffer: fix ring_buffer_event_length() Steven Rostedt
2009-01-08  5:29 ` Andrew Morton
2009-01-08 11:55   ` Ingo Molnar
2009-01-08 19:26     ` Andrew Morton [this message]
2009-01-11  3:44       ` Ingo Molnar
2009-01-08 14:18   ` Steven Rostedt
2009-01-08 14:46     ` Ingo Molnar
2009-01-08 11:59 ` Ingo Molnar
2009-01-08 14:28   ` Steven Rostedt
2009-01-08 14:40     ` 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=20090108112628.aa48a3f9.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=robert.richter@amd.com \
    --cc=rostedt@goodmis.org \
    /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.