All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jesse Barnes <jbarnes@engr.sgi.com>,
	Albert Cahalan <albert@users.sourceforge.net>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] I/O space write barrier
Date: Tue, 05 Oct 2004 16:57:41 -0700	[thread overview]
Message-ID: <52r7ocra4q.fsf@topspin.com> (raw)
In-Reply-To: <1097016099.27222.14.camel@gaston> (Benjamin Herrenschmidt's message of "Wed, 06 Oct 2004 08:41:40 +1000")

    Benjamin> I don't understand that neither. You can never guarantee
    Benjamin> any ordering between writes from different CPUs unless
    Benjamin> you have a sinlock. If you have an ordering problem with
    Benjamin> spinlocks, then it's a totally different issue, a bit
    Benjamin> more like MMIO vs. cacheable mem that we have on PPC. If
    Benjamin> this is the problem you are trying to chase, then we
    Benjamin> could use such a barrier on ppc too and make it a hard
    Benjamin> sync, but it has nothing to do with the write barrier we
    Benjamin> already have in our IO accessors...

As I understand it, the problem is that on some Itanium boxes, it's
possible to have the following code run:

	CPU 1				CPU 2
    spin_lock(&devlock);
    writel(foo);
    spin_unlock(&devlock);

				    spin_lock(&devlock);
				    writel(bar);
				    spin_unlock(&devlock);

and still have bar arrive at the device before foo.  One possibility
would be to add a read after the writel() to flush the posted write.
The proposed mmiowb() function is somewhat lighter weight -- it
guarantees that later writes will not hit the device before any writes
already issued, but it doesn't say anything about writes making it all
the way to the device.

I could be wrong but I think that the eieio in the ppc IO write
functions should be strong enough that mmiowb() can be a no-op.

By the way, are the ordering rules different for ppc32 and ppc64?  I
notice that the ppc32 out_xxx() functions do eieio while the ppc64
versions do a full sync.

Thanks,
  Roland



  parent reply	other threads:[~2004-10-05 23:58 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-04 20:39 [PATCH] I/O space write barrier Albert Cahalan
2004-10-04 21:20 ` Jesse Barnes
2004-10-05  0:32   ` Albert Cahalan
2004-10-05  1:22     ` Benjamin Herrenschmidt
2004-10-05  2:26       ` Jesse Barnes
2004-10-05  3:04         ` Benjamin Herrenschmidt
2004-10-05 15:33           ` Jesse Barnes
2004-10-05 22:41             ` Benjamin Herrenschmidt
2004-10-05 23:09               ` Jesse Barnes
2004-10-05 23:57               ` Roland Dreier [this message]
2004-10-06  1:45                 ` Benjamin Herrenschmidt
2004-10-05  2:33     ` Jesse Barnes
  -- strict thread matches above, loose matches on Subject: below --
2004-10-21 23:13 Jesse Barnes
2004-10-21 23:13 ` Jesse Barnes
2004-10-22  1:01 ` Grant Grundler
2004-10-22  1:01   ` Grant Grundler
2004-10-22  3:05   ` Jesse Barnes
2004-10-22  3:05     ` Jesse Barnes
2004-10-22  4:26     ` Greg Banks
2004-10-22  4:26       ` Greg Banks
2004-10-22 15:26     ` Grant Grundler
2004-10-22 15:26       ` Grant Grundler
2004-10-05 22:38 Jesse Barnes
2004-09-27 18:03 Jesse Barnes
2004-09-29 10:36 ` Greg Banks
2004-09-29 20:35   ` David S. Miller
2004-09-29 20:43     ` Jesse Barnes
2004-09-29 20:50       ` David S. Miller
2004-09-30  2:23         ` Greg Banks
2004-09-29 22:55 ` Jesse Barnes
2004-09-30  7:15   ` Jeremy Higdon
2004-09-30 21:21     ` Guennadi Liakhovetski
2004-10-16  0:38       ` Jeremy Higdon
2004-10-16  3:20         ` Matthew Wilcox
2004-10-16  3:31           ` Jeremy Higdon
2004-09-23 18:48 Jesse Barnes
2004-09-23 19:03 ` James Bottomley
2004-09-23 19:07   ` Jesse Barnes
2004-09-23 19:27     ` James Bottomley
2004-09-23 19:41       ` Jesse Barnes
2004-09-23 19:57       ` Jeremy Higdon
2004-09-23 22:22       ` Jeremy Higdon
2004-09-23 23:36         ` James Bottomley
2004-09-24  5:03           ` Jeremy Higdon
2004-09-23 19:55     ` Jeremy Higdon
2004-09-23 20:09       ` Jesse Barnes
2004-09-27  0:45 ` Benjamin Herrenschmidt
2004-09-27 15:41   ` Jesse Barnes
2004-09-22 15:45 Jesse Barnes

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=52r7ocra4q.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=albert@users.sourceforge.net \
    --cc=benh@kernel.crashing.org \
    --cc=jbarnes@engr.sgi.com \
    --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 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.