All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Tell the world we gave up on pushing CC_OPTIMIZE_FOR_SIZE
Date: Fri, 23 Nov 2012 19:10:40 -0500	[thread overview]
Message-ID: <20121124001040.GA29164@redhat.com> (raw)
In-Reply-To: <20121122081041.GA380@tugrik.mns.mnsspb.ru>

On Thu, Nov 22, 2012 at 12:10:41PM +0400, Kirill Smelkov wrote:
 
 > Linus, maybe you missed this. What is the reason telling people
 > CC_OPTIMIZE_FOR_SIZE should be Y if we actually do otherwise?
 > 
 > 
 > commit 281dc5c5ec0fb299514567cbc358562649c1af95
 > Author: Linus Torvalds <torvalds@linux-foundation.org>
 > Date:   Sun May 22 14:30:36 2011 -0700
 > 
 >     Give up on pushing CC_OPTIMIZE_FOR_SIZE
 >     
 >     I still happen to believe that I$ miss costs are a major thing, but
 >     sadly, -Os doesn't seem to be the solution.  With or without it, gcc
 >     will miss some obvious code size improvements, and with it enabled gcc
 >     will sometimes make choices that aren't good even with high I$ miss
 >     ratios.
 >     
 >     For example, with -Os, gcc on x86 will turn a 20-byte constant memcpy
 >     into a "rep movsl".  While I sincerely hope that x86 CPU's will some day
 >     do a good job at that, they certainly don't do it yet, and the cost is
 >     higher than a L1 I$ miss would be.
 >     
 >     Some day I hope we can re-enable this.
 >     
 >     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
 > 
 > diff --git a/init/Kconfig b/init/Kconfig
 > index 4986ecc..ffcdad7 100644
 > --- a/init/Kconfig
 > +++ b/init/Kconfig
 > @@ -908,7 +908,6 @@ endif
 >  
 >  config CC_OPTIMIZE_FOR_SIZE
 >         bool "Optimize for size"
 > -       default y
 >         help
 >           Enabling this option will pass "-Os" instead of "-O2" to gcc
 >           resulting in a smaller kernel.
 
FWIW, we gave up using this in Fedora quite a few releases back because we
kept finding workloads that it truly sucked on.
For code that is quite bloaty and not particularly performance critical,
maybe we could move -Os to individual directories.

	Dave

  reply	other threads:[~2012-11-24  0:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-02 11:41 [PATCH] Tell the world we gave up on pushing CC_OPTIMIZE_FOR_SIZE Kirill Smelkov
2012-11-22  8:10 ` Kirill Smelkov
2012-11-24  0:10   ` Dave Jones [this message]
2013-01-17  8:58     ` Borislav Petkov

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=20121124001040.GA29164@redhat.com \
    --to=davej@redhat.com \
    --cc=kirr@mns.spb.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.