public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Adrian Bunk <bunk@kernel.org>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [2.6 patch] kernel/sched*: optimize inlining
Date: Sun, 11 May 2008 22:38:27 +0200	[thread overview]
Message-ID: <20080511203827.GA850@uranus.ravnborg.org> (raw)
In-Reply-To: <20080511200016.GH1645@cs181133002.pp.htv.fi>

> > 
> > You continue to fail to acknowledge that it is valueable information
> > that we pass gcc a _hint_ that it is a good idea to inline certain
> > functions.
> > 
> > The inline hint is there to tell gcc that it shall inline this function
> > in cases where it usual think it should not do so. Which invietably
> > will result in a larger codesize in some cases.
> 
> We also give gcc an explicit "Optimize for size.".

gcc was asked to optimize for size in general as per the commandline option.
But on a much more fine grained level gcc is given a hint that
this function would be a good idea to inline.

And I really expect gcc to pay most attention to the more specific
information provided for a single function than a general commandline option.

> 
> If gcc would decide to ignore all hints that increase code size with -Os 
> that would be perfectly fine behaviour.
No - see above.

> 
> All the "optimized inlining" does is to allow gcc to no longer inline 
> functions marked as "inline" if it prefers not to do so.
The "optimized inlining" allows gcc (if gcc > 4.0) to make an educated
guess if it is worhtwhile to inline a function or not. And when deciding
to do so or not gcc may include many different factors inlcuding
but not limited to -s.
And this is certainly optimized compared to the situation where
inline equals to always_inline.
Keep in mind that we often perfer to have _less_ inlining than we have
today for debugging ease. And this is what we get with optimized inlining
compared to farced inlining.

> 
> And what exactly is your problem with my patch if you consider the 
> general "optimized inlining" approach correct?

I've already listed two things:
-> It is no longer a simple kconfig change to try with or without.
-> It is independent on gcc version

And for fast path code like sched.c I would much assume a proper analysis
when it is acceptable to remove the inline hint is almost mandatory.
Your patch looks much more like a simple s/ inline//g.
Especially since removing the inline hint is not configurable and
thus it is not an easy task to ask some to try with or without this
patch in two weeks from now where a clean revert is not possible.

	Sam

  reply	other threads:[~2008-05-11 20:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-11  9:21 [2.6 patch] kernel/sched*: optimize inlining Adrian Bunk
2008-05-11 11:18 ` Andreas Mohr
2008-05-11 12:52   ` Adrian Bunk
2008-05-11 17:22     ` Ray Lee
2008-05-11 17:52 ` Sam Ravnborg
2008-05-11 18:49   ` Adrian Bunk
2008-05-11 19:42     ` Sam Ravnborg
2008-05-11 20:00       ` Adrian Bunk
2008-05-11 20:38         ` Sam Ravnborg [this message]
2008-05-11 21:19           ` Adrian Bunk
2008-05-11 21:44             ` Sam Ravnborg
2008-05-11 22:11               ` Adrian Bunk
2008-05-12  6:57                 ` Sam Ravnborg
2008-05-12  7:45                   ` Adrian Bunk
     [not found] <fa.kBy7Kr77qTR+lDVDv4OKx7n5m1Y@ifi.uio.no>
     [not found] ` <fa.8/KGOoB8CQ+uVBJXmUNHaIfXQSg@ifi.uio.no>
     [not found]   ` <fa.sBJgAJSNbPht40KbEGBXczzW3vQ@ifi.uio.no>
2008-05-11 17:25     ` Robert Hancock

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=20080511203827.GA850@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox