public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <andi@firstfloor.org>
Cc: akpm@linux-foundation.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] [3/5] Mark complex bitops.h inlines as __always_inline
Date: Wed, 7 Jan 2009 14:26:53 +0100	[thread overview]
Message-ID: <20090107132653.GA22229@elte.hu> (raw)
In-Reply-To: <20090106143215.GD496@one.firstfloor.org>


* Andi Kleen <andi@firstfloor.org> wrote:

> > Your patch is wrong because it prevents a good compiler from doing the 
> > right inlining decisions.
> 
> One or two instruction bitops should be always inlined, not inlining 
> them always generates much worse code than inlining them. That's easy to 
> prove just based on code size: the call overhead is larger than the 
> inlined code.

You are arguing this backwards. Firstly, CONFIG_OPTIMIZE_INLINING is 
disabled by default. If you enable it, and if CONFIG_OPTIMIZE_INLINING=y 
creates a larger kernel for you, then either do not enable it - or send 
numbers so that we can see the true impact of this change.

Yes, simple functions should always be inlined, nobody will argue about 
that. But GCC's inliner will never be fixed (for the kernel domain at 
least) if we keep working it around and if we keep micro-managing it.

We work around GCC bugs only if it hurts visibly (and generally if it 
affects default-enabled features/optimizations): if it can be quantified 
either via stability/robustness problems or there's excesssive size / 
efficiency problems.

You simply have not made that argument via any numbers here. So i have no 
reason to take your patch just yet, unless you provide some clear, 
documented, measurable benefit.

	Ingo

  reply	other threads:[~2009-01-07 13:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-04 23:36 [PATCH] [0/5] Couple of x86 patches for 2.6.29 Andi Kleen
2009-01-04 23:36 ` [PATCH] [1/5] Only scan the root bus in early PCI quirks Andi Kleen
2009-01-04 23:51   ` Yinghai Lu
2009-01-05  1:46     ` Andi Kleen
2009-01-04 23:36 ` [PATCH] [2/5] Allow HPET force enable on ICH10 HPET Andi Kleen
2009-01-04 23:36 ` [PATCH] [3/5] Mark complex bitops.h inlines as __always_inline Andi Kleen
2009-01-06  0:03   ` Andrew Morton
2009-01-06 10:17   ` Ingo Molnar
2009-01-06 14:32     ` Andi Kleen
2009-01-07 13:26       ` Ingo Molnar [this message]
2009-01-07 19:46         ` Andi Kleen
2009-01-06 19:17   ` Hugh Dickins
2009-01-07 13:18     ` Ingo Molnar
2009-01-08  2:16       ` Hugh Dickins
2009-01-08  5:07         ` Andi Kleen
2009-01-08  8:04       ` H. Peter Anvin
2009-01-04 23:36 ` [PATCH] [4/5] Use asm stubs for 32bit sigreturn codes Andi Kleen
2009-01-05  0:08   ` H. Peter Anvin
2009-01-04 23:36 ` [PATCH] [5/5] Avoid theoretical vmalloc fault loop Andi Kleen
2009-01-05 11:47   ` Nick Piggin

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=20090107132653.GA22229@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@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