linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>,
	linux-ppc-embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: pte_update and 64-bit PTEs on PPC32?
Date: Fri, 8 Apr 2005 23:04:58 +0200	[thread overview]
Message-ID: <20050408210458.GA16672@iram.es> (raw)
In-Reply-To: <8497276598d775128a73efb06803a9ba@freescale.com>

On Fri, Apr 08, 2005 at 02:01:13PM -0500, Kumar Gala wrote:
> >Now that I read it carefully, I realize that I was wrong. But there
> >is still some room for optimization; the parameter that you don't
> >need is %3: simply replace lwzx %0,0,%3 by lwz %0,-4(%4).
> 
> Doesn't help, realize that we are going to have "r3" with a pointer to 
> pte.  There is no way w/o an add to get to the next word for the lwarx.

I'd have to see the context. One less parameter to an asm block may
also make the compiler life easier. 

> 
> >But I'm not sure that OOO cannot play tricks on you, what guarantees
> > that the lwz is done after lwarx?
> 
> I'm assuming since its a single asm block, gcc is not allowed to 
> reorder it.

Not GCC, but the hardware. If loads can pass loads and lwarx has
more internal housekeeping overhead (obviously) than lwz. Especially
in the case of a processor with 2 LSU:
- lwarx issued to LSU1
- lwz issued LSU2 in the same clock cycle

I'm not sure at all that that you are guaranteed not to get 
potentially stale data from the lwz on SMP. Loads are weekly 
ordered in general wrt each other and lwarx is no exception
AFAIR. The fact that the two words are guaranteed to be in 
the same cache line makes it extremely unlikely, but not 
impossible.

	Gabriel

  reply	other threads:[~2005-04-08 21:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-06  6:51 pte_update and 64-bit PTEs on PPC32? Kumar Gala
2005-04-06  6:53 ` Benjamin Herrenschmidt
2005-04-06 16:44   ` Kumar Gala
2005-04-06 17:20     ` Chris Friesen
2005-04-06 17:58       ` Kumar Gala
2005-04-06 21:33         ` Kumar Gala
2005-04-08  8:26           ` Gabriel Paubert
2005-04-08 14:08             ` Kumar Gala
2005-04-08 18:44               ` Gabriel Paubert
2005-04-08 19:01                 ` Kumar Gala
2005-04-08 21:04                   ` Gabriel Paubert [this message]
2005-04-08 21:31                     ` Dan Malek
2005-04-08 21:44                       ` Gabriel Paubert
2005-04-08 23:32                     ` Kumar Gala
2005-04-09  0:32                 ` Paul Mackerras
2005-04-06 22:22     ` Benjamin Herrenschmidt
2005-04-06 22:27       ` Kumar Gala
2005-04-07 11:15     ` Benjamin Herrenschmidt

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=20050408210458.GA16672@iram.es \
    --to=paubert@iram.es \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).