public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Adrian Bunk <bunk@kernel.org>
Cc: Andreas Mohr <andi@lisas.de>, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] kernel/sched*: optimize inlining
Date: Sun, 11 May 2008 11:25:49 -0600	[thread overview]
Message-ID: <48272C1D.8020301@shaw.ca> (raw)
In-Reply-To: <fa.sBJgAJSNbPht40KbEGBXczzW3vQ@ifi.uio.no>

Adrian Bunk wrote:
> On Sun, May 11, 2008 at 01:18:20PM +0200, Andreas Mohr wrote:
>> [manual reply, no access to original content]
>>
>> Hi,
>>
>> rather NACKish here (from my minor side, that is, since there are no
>> useful explanations, and in the case of a lack of explanations no
>> backing numbers either which would have been helpful to resolve this ;).
>>
>> "x86: add optimized inlining"
>> (http://kerneltrap.org/mailarchive/git-commits-head/2008/4/26/1612644)
>> does not really say anything relevant to your patch, AFAICS.
>>
>> That one simply says that previously every inline was force-inlined (ugh),
>> which now gcc is allowed to properly decide by itself now. This, however,
>> does _NOT_ imply that it's now somehow fully sufficient for a perfect outcome
>> to simply remove all open-coded "inline"s.
> 
> They both do the same - gcc is no longer forced to inline these 
> functions.
> 
> With either my patch or the "optimized inlining" it's 100% gcc's 
> choice whether or not to inline functions marked as "inline" in 
> kernel/sched* .
> 
> If you didn't complain when "x86: add optimized inlining" got into 
> Linus' tree you can't validly complain about my patch.

It's not really the same thing. Not forcing gcc to do the inlining where 
it's marked is one thing, but removing the hint to inline the function 
entirely is something else. In this case without the hint it clearly 
makes the wrong decision, since there is no reason to not inline a 
function that just calls another function.

GCC 4.3 is supposed to have some improvements in this area with 
pre-inline optimization and early inlining, but older gcc versions may 
still have this issue.

       reply	other threads:[~2008-05-11 17:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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
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

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=48272C1D.8020301@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=andi@lisas.de \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox