[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0609171919030.4388@g5.osdl.org>
Date: Sun, 17 Sep 2006 19:24:31 -0700 (PDT)
From: Linus Torvalds <torvalds@...l.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc: Linux Kernel list <linux-kernel@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Jeff Garzik <jgarzik@...ox.com>,
Paul Mackerras <paulus@...ba.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC] MMIO accessors & barriers documentation #2
On Mon, 18 Sep 2006, Benjamin Herrenschmidt wrote:
>
> Class 1: Ordered accessors
> --------------------------
>
> 1- {read,write}{b,w,l,q} : MMIO accessors. Those accessors provide
> all MMIO ordering requirements. They are thus called "fully ordered".
> That is #1, #2 and #4 for writes and #1 and #3 for reads.
Well, it's already not defined to be #4 right now on SGI boxes, and we
have that (badly named) mmiowb() thing to enforce #4, so I think we should
just accept that write[bwl]() it's _that_ ordered.
And on x86, we _already_ depend on "wmb()" to be a "normal write to MMIO
write" barrier, which is technically wrong and bad. Again, thanks to
mmiowb(), normal memory accesses and MMIO accesses have already been
defined to not be in the same "ordering domain", so "wmb()" is technically
wrong and may not order a regular write wrt a MMIO (because it doesn't do
so for the other order: MMIO->spin_unlock).
So I think we should just admit that at least MMIO _stores_ are already
not entirely ordered, and not try to strengthen the rules for the current
setup (and just try to clarify the currently accepted semantics).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists