All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] don't udelay() in sn_mmiob
Date: Sat, 29 May 2004 14:31:45 +0000	[thread overview]
Message-ID: <20040529143145.GB15037@sgi.com> (raw)
In-Reply-To: <200405261749.02254.jbarnes@engr.sgi.com>

On Fri, May 28, 2004 at 05:57:33PM -0700, Seth, Rohit wrote:
> Jack Steiner <> wrote on Friday, May 28, 2004 10:35 AM:
> 
> > On Fri, May 28, 2004 at 12:28:55PM -0500, Jack Steiner wrote:
> >> On Thu, May 27, 2004 at 05:06:31PM -0400, Jesse Barnes wrote:
> >>> On Thursday, May 27, 2004 4:46 pm, David Mosberger wrote:
> >>>> Wouldn't you want at least a cpu_relax() in that loop?
> >>> 
> >>> That'll cause the CPU to switch to the other thread if it's SMT so
> >>> it won't spin waiting for the access to complete?  If so, then yes.
> >>> Here's an updated patch.
> > 
> > Whoops, I posted this response to the wrong mail. I was replying to
> > the question about whether the code should have a "cpu_relax()". 
> > 
> >> 
> >> I didn't think the code would actually spin.
> >> 
> >> sn_mmiob() is something like:
> >> 
> >>     1:	ld.acq r8=...
> >>     	;;
> >> 	cmp.eq p8,p0=r8,r9
> >>    (p8)	br 1b
> >> 
> >> The "load" is an uncached load. Won't the pipeline stall on the cmp
> >> waiting for data to arrive. I would not have expected that a
> >> cpu_relax() would have been needed here.
> >> 
> 
> You are right that pipeline will stall on the cmp instruction.  But if
> you could put the hint@pause between ld and cmp instructions then that
> would allow current execution stream to give up resources to other
> execution stream (if applicable) for the time that data takes to come
> from main memory.
> 
> -rohit

I thought the cpu would automatically switch on a cache miss & I assumed that
a switch would occur on a UC ref. Or am I thinking of a different processor?

If you follow the logic that is cpu_relax is useful in the sn_mmiob()
function, shouldn't there be a cpu_relax() after EVERY uncached load 
that is immediately (or closely) followed by an instruction that 
consumes the data.

What are the conditions that cause a switch between execution streams? 

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.



      parent reply	other threads:[~2004-05-29 14:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26 21:49 [PATCH] don't udelay() in sn_mmiob Jesse Barnes
2004-05-27 20:46 ` David Mosberger
2004-05-27 21:06 ` Jesse Barnes
2004-05-27 21:29 ` David Mosberger
2004-05-28 17:28 ` Jack Steiner
2004-05-28 17:35 ` Jack Steiner
2004-05-29  0:57 ` Seth, Rohit
2004-05-29 14:31 ` Jack Steiner [this message]

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=20040529143145.GB15037@sgi.com \
    --to=steiner@sgi.com \
    --cc=linux-ia64@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 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.