From: Roland Dreier <rdreier@cisco.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Paul Mackerras <paulus@samba.org>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [RFC] MMIO accessors & barriers documentation
Date: Mon, 11 Sep 2006 16:08:23 -0700 [thread overview]
Message-ID: <adar6yi2e8o.fsf@cisco.com> (raw)
In-Reply-To: <1158015394.3879.82.camel@localhost.localdomain> (Benjamin Herrenschmidt's message of "Tue, 12 Sep 2006 08:56:34 +1000")
Benjamin> and rmb is heavy handed for a compiler barrier :) what
Benjamin> you might need on some platforms is an rmb between the
Benjamin> MMIO read of whatever status/index register and the
Benjamin> following memory reads of descriptors, and you may want
Benjamin> an rmb in case where it matters if the chip has been
Benjamin> changing a value behind your back (which it generally
Benjamin> doesn't) but that's pretty much it....
In drivers/infiniband/hw/mthca/mthca_eq.c, there is:
while ((eqe = next_eqe_sw(eq))) {
/*
* Make sure we read EQ entry contents after we've
* checked the ownership bit.
*/
rmb();
switch (eqe->type) {
where next_eqe_sw() checks a "valid" bit of a 32-byte event queue
entry that is DMA-ed into memory by the device. The device is careful
to write the valid bit (byte actually) last, but on PowerPC 970
without the rmb(), we actually saw the CPU reordering the read of
eqe->type (which is another field of the EQ entry written by the
device) so it happened before the entry was valid, but then executing
the check of the valid bit far enough into the future so that the
entry tested as valid.
This isn't that surprising: if you had two CPUs, with one CPU writing
into a queue and the other CPU polling the queue, you would obviously
need smp_rmb() on the CPU doing the reading. But somehow it's not
quite as obvious when a device plays the role of one of the CPUs.
Of course there's no MMIO anywhere in sight here, so this isn't
directly applicable I guess.
- R.
next prev parent reply other threads:[~2006-09-11 23:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-11 4:03 [RFC] MMIO accessors & barriers documentation Benjamin Herrenschmidt
2006-09-11 8:57 ` Alan Cox
2006-09-11 9:17 ` Benjamin Herrenschmidt
2006-09-11 10:07 ` Alan Cox
2006-09-11 9:59 ` Benjamin Herrenschmidt
2006-09-11 17:26 ` Alan Cox
2006-09-11 21:29 ` Benjamin Herrenschmidt
2006-09-12 5:48 ` Eric W. Biederman
2006-09-12 5:56 ` Benjamin Herrenschmidt
2006-09-12 6:27 ` Eric W. Biederman
2006-09-12 7:13 ` Benjamin Herrenschmidt
2006-09-12 15:19 ` Segher Boessenkool
2006-09-12 21:22 ` Benjamin Herrenschmidt
2006-09-13 0:12 ` Segher Boessenkool
2006-09-13 1:34 ` Benjamin Herrenschmidt
2006-09-11 18:39 ` Jesse Barnes
2006-09-11 21:45 ` Benjamin Herrenschmidt
2006-09-11 21:54 ` Jeff Garzik
2006-09-11 22:56 ` Benjamin Herrenschmidt
2006-09-11 23:08 ` Roland Dreier [this message]
2006-09-11 23:18 ` Benjamin Herrenschmidt
2006-09-11 23:24 ` Jeff Garzik
2006-09-12 0:46 ` Benjamin Herrenschmidt
2006-09-12 15:32 ` Segher Boessenkool
2006-09-11 22:05 ` Jesse Barnes
2006-09-11 23:01 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2006-09-12 5:33 Albert Cahalan
2006-09-12 5:48 ` 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=adar6yi2e8o.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=jbarnes@virtuousgeek.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=segher@kernel.crashing.org \
--cc=torvalds@osdl.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