public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Emmanuel Fleury <emmanuel.fleury@labri.fr>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch] i386: use C code for current_thread_info()
Date: Mon, 12 Jun 2006 19:55:09 +0200	[thread overview]
Message-ID: <20060612175509.GC30587@stusta.de> (raw)
In-Reply-To: <200606121317_MC3-1-C23A-4F2D@compuserve.com>

On Mon, Jun 12, 2006 at 01:14:34PM -0400, Chuck Ebbert wrote:
> In-Reply-To: <448C85B7.1010902@labri.fr>
> 
> On Sun, 11 Jun 2006 23:05:59 +0200, Emmanuel Fleury wrote:
> 
> > > Looking at the generated code, it seems the compiler just makes dumb
> > > choices and tends to recompute current_thread_info() in unlikely code
> > > paths even when there is no register pressure.  4.0.2 makes better
> > > choices.
> >
> > What size with gcc 4.1.2 ? (just curiosity)
> 
> The 3.3 vs 4.0 comparisons were with two different configs, so only
> relative gain/loss with asm vs. C could be compared.
> 
> I downloaded gcc 4.1.1 and compared to 4.0.2 with the exact same config,
> since I was curious how much better it might be overall.
> 
> gcc 4.0.2:
>    text	   data	    bss	    dec	    hex	filename
> 3645212	 555556	 312024	4512792	 44dc18	2.6.17-rc6-nb-C/vmlinux
> 3647276	 555556	 312024	4514856	 44e428	2.6.17-rc6-nb-asm/vmlinux
>   -2064
> 
> gcc 4.1.1:
>    text	   data	    bss	    dec	    hex	filename
> 3614686	 520416	 311672	4446774	 43da36	2.6.17-rc6-nb-C/vmlinux
> 3616942	 520416	 311672	4449030	 43e306	2.6.17-rc6-nb-asm/vmlinux
>   -2256
> 
> Kernel code starts out ~30K bytes smaller with gcc 4.1 and using C
> for current_thread_info() helps even more than with 4.0.  Nice...
> 
> Maybe a patch that enables C code for gcc 4.0+ would work, since
> on 3.3 the asm code is better?


No.

gcc 3.3 is still supported, and it's important that the kernel runs 
correctly when compiled with this compiler (implying workarounds for 
compiler bugs).

But for best performance, people should always use the latest gcc.
(And if there was a case where usage of the latest gcc would give a 
 worse performance, that would be a bug in gcc and/or the kernel that
 should be reported.)

So unless there's a _really_ significant regression with older gcc 
versions, adding #ifdef's for such micro optimizations is not worth it.


> Chuck


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2006-06-12 17:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-12 17:14 [patch] i386: use C code for current_thread_info() Chuck Ebbert
2006-06-12 17:55 ` Adrian Bunk [this message]
2006-06-12 18:48 ` Andreas Mohr
  -- strict thread matches above, loose matches on Subject: below --
2006-06-13  5:26 Albert Cahalan
2006-06-13  1:50 Chuck Ebbert
2006-06-13  6:43 ` Andreas Mohr
2006-06-13  9:27   ` Avi Kivity
2006-06-11 20:43 Chuck Ebbert
2006-06-11 21:05 ` Emmanuel Fleury
2006-06-11 19:07 Chuck Ebbert
2006-06-11 19:33 ` Linus Torvalds
2006-06-11 19:42 ` Jan Engelhardt
2006-06-11 20:33   ` Jan Engelhardt
2006-06-11 20:44   ` Alistair John Strachan
2006-06-12  8:10     ` Andi Kleen

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=20060612175509.GC30587@stusta.de \
    --to=bunk@stusta.de \
    --cc=76306.1226@compuserve.com \
    --cc=emmanuel.fleury@labri.fr \
    --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