All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Vargas <windenntw@gmail.com>
To: Paul Mackerras <paulus@samba.org>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	linux-kernel@vger.kernel.org, linuxppc64-dev@ozlabs.org
Subject: Re: prefetch on ppc64
Date: Wed, 30 Mar 2005 07:38:10 +0200	[thread overview]
Message-ID: <69304d110503292138620d4587@mail.gmail.com> (raw)
In-Reply-To: <16970.9005.721117.942549@cargo.ozlabs.ibm.com>

On Wed, 30 Mar 2005 13:55:25 +1000, Paul Mackerras <paulus@samba.org> wrote:
> Serge E. Hallyn writes:
> 
> > While investigating the inordinate performance impact one of my patches
> > seemed to be having, we tracked it down to two hlist_for_each_entry
> > loops, and finally to the prefetch instruction in the loop.
> 
> I would be interested to know what results you get if you leave the
> loops using hlist_for_each_entry but change prefetch() and prefetchw()
> to do the dcbt or dcbtst instruction only if the address is non-zero,
> like this:
> 
> static inline void prefetch(const void *x)
> {
>         if (x)
>                 __asm__ __volatile__ ("dcbt 0,%0" : : "r" (x));
> }
> 
> static inline void prefetchw(const void *x)
> {
>         if (x)
>                 __asm__ __volatile__ ("dcbtst 0,%0" : : "r" (x));
> }
> 
> It seems that doing a prefetch on a NULL pointer, while it doesn't
> cause a fault, does waste time looking for a translation of the zero
> address.
> 
> Paul.

Don't know exactly about power5, but G5 processor is described on IBM
docs as doing automatic whole-page prefetch read-ahead when detecting
linear accesses.

-- 
Greetz, Antonio Vargas aka winden of network

http://wind.codepixel.com/

Las cosas no son lo que parecen, excepto cuando parecen lo que si son.

  reply	other threads:[~2005-03-30  5:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-30  3:40 prefetch on ppc64 Serge E. Hallyn
2005-03-30  3:55 ` Paul Mackerras
2005-03-30  5:38   ` Antonio Vargas [this message]
2005-03-30  6:00     ` Paul Mackerras
2005-03-30 14:33   ` Serge E. Hallyn

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=69304d110503292138620d4587@mail.gmail.com \
    --to=windenntw@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=serue@us.ibm.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 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.