public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Andreas Mohr <andi@rhlx01.fht-esslingen.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-kernel@vger.kernel.org,
	Chuck Ebbert <76306.1226@compuserve.com>,
	Zachary Amsden <zach@vmware.com>,
	Jan Beulich <jbeulich@novell.com>, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH RFC 0/6] Implement per-processor data areas for i386.
Date: Sun, 27 Aug 2006 20:35:34 +0200	[thread overview]
Message-ID: <200608272035.34839.ak@suse.de> (raw)
In-Reply-To: <20060827182708.GB12642@rhlx01.fht-esslingen.de>

On Sunday 27 August 2006 20:27, Andreas Mohr wrote:
> Hi,
> 
> On Sun, Aug 27, 2006 at 08:04:38PM +0200, Andi Kleen wrote:
> > 
> > > Something like that had to be done eventually about the inefficient
> > > current_thread_info() mechanism, 
> > 
> > Inefficient? It's two fast instructions. I won't call that inefficient.
> 
> And that AGI stall?

What AGI stall?

[btw AGI stall is an outdated concept on modern x86 CPUs]

> > > I guess it's due to having tried that on an older installation with gcc 3.2,
> > > which probably does less efficient opcode merging of current_thread_info()
> > > requests compared to a current gcc version.
> > 
> > gcc normally doesn't merge inline assembly at all.
> 
> Depends on use of volatile, right?

No.  It can only merge statements it knows anything about, and it doesn't
about inline assembly.

> OK, so probably there was no merging of separate requests,
> but opcode intermingling could have played a role.

It seems to make some difference if it's able to move asm around
and if they don't have memory clobbers. memory clobbers really seem
to cause much worse code in the whole function.

But current_thread_info didn't have that.

-Andi


  reply	other threads:[~2006-08-27 18:36 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-27  8:44 [PATCH RFC 0/6] Implement per-processor data areas for i386 Jeremy Fitzhardinge
2006-08-27  8:44 ` [PATCH RFC 1/6] Basic definitions for i386-pda Jeremy Fitzhardinge
2006-08-27  8:44 ` [PATCH RFC 2/6] Initialize the per-CPU data area Jeremy Fitzhardinge
2006-08-27  8:44 ` [PATCH RFC 3/6] Use %gs as the PDA base-segment in the kernel Jeremy Fitzhardinge
2006-08-27  9:49   ` Keith Owens
2006-08-27 10:01     ` Jeremy Fitzhardinge
2006-08-27 15:57   ` Andi Kleen
2006-08-27 16:36     ` Jeremy Fitzhardinge
2006-08-27 17:20     ` Jeremy Fitzhardinge
2006-08-27 18:19       ` Andi Kleen
2006-08-27 20:03         ` Jan Engelhardt
2006-08-27 23:38         ` Jeremy Fitzhardinge
2006-08-28  9:51         ` Jan Beulich
2006-08-28 14:54           ` H. J. Lu
2006-08-28 17:24         ` H. Peter Anvin
2006-08-27  8:44 ` [PATCH RFC 4/6] Fix places where using %gs changes the usermode ABI Jeremy Fitzhardinge
2006-08-27 15:59   ` Andi Kleen
2006-08-27 16:37     ` Jeremy Fitzhardinge
2006-08-27  8:44 ` [PATCH RFC 5/6] Implement smp_processor_id() with the PDA Jeremy Fitzhardinge
2006-08-27  8:44 ` [PATCH RFC 6/6] Implement "current" " Jeremy Fitzhardinge
2006-08-27 16:01   ` Andi Kleen
2006-08-27 16:38     ` Jeremy Fitzhardinge
2006-08-27  9:47 ` [PATCH RFC 0/6] Implement per-processor data areas for i386 Arjan van de Ven
2006-08-27 16:46   ` Jeremy Fitzhardinge
2006-08-27 17:44     ` Arjan van de Ven
2006-08-27 18:07       ` Andi Kleen
2006-08-27 18:27         ` Jeremy Fitzhardinge
2006-08-27 16:01 ` Andi Kleen
2006-08-27 16:41   ` Jeremy Fitzhardinge
2006-08-27 17:21 ` Andreas Mohr
2006-08-27 17:34   ` Jeremy Fitzhardinge
2006-08-27 18:23     ` Andreas Mohr
2006-08-27 18:04   ` Andi Kleen
2006-08-27 18:27     ` Andreas Mohr
2006-08-27 18:35       ` Andi Kleen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-08-28  9:06 Chuck Ebbert
2006-08-30  9:00 Chuck Ebbert
2006-08-30  9:17 ` Jeremy Fitzhardinge
2006-08-30 12:33 Chuck Ebbert
2006-08-30 12:54 ` Andi Kleen
2006-08-30 16:39 ` Jeremy Fitzhardinge
2006-08-30 16:48   ` Andi Kleen
2006-08-30 17:13     ` Jeremy Fitzhardinge
2006-08-30 17:32       ` 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=200608272035.34839.ak@suse.de \
    --to=ak@suse.de \
    --cc=76306.1226@compuserve.com \
    --cc=akpm@osdl.org \
    --cc=andi@rhlx01.fht-esslingen.de \
    --cc=jbeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zach@vmware.com \
    /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