Re: MMIO and gcc re-ordering issue
From: Trent Piepho
Date: Tue Jun 03 2008 - 17:59:42 EST
On Tue, 3 Jun 2008, Matthew Wilcox wrote:
On Tue, Jun 03, 2008 at 12:57:56PM -0700, Trent Piepho wrote:
On Tue, 3 Jun 2008, Matthew Wilcox wrote:
On Tue, Jun 03, 2008 at 11:47:00AM -0700, Trent Piepho wrote:
On Tue, 3 Jun 2008, Linus Torvalds wrote:
On Tue, 3 Jun 2008, Nick Piggin wrote:
Linus: on x86, memory operations to wc and wc+ memory are not ordered
with one another, or operations to other memory types (ie. load/load
and store/store reordering is allowed). Also, as you know, store/load
reordering is explicitly allowed as well, which covers all memory
types. So perhaps it is not quite true to say readl/writel is strongly
ordered by default even on x86. You would have to put in some
mfence instructions in them to make it so.
So on x86, these could be re-ordered?
writel(START_OPERATION, CONTROL_REGISTER);
status = readl(STATUS_REGISTER);
You wouldn't ask for write-combining memory mapping for control or
status registers.
But Nick said, "store/load reordering is explicitly allowed as well, which
covers *all* memory types."
Then Nick is confused. PCI only defines one way to flush posted writes
to a device -- doing a read from it. There's no way that reads can
be allowed to pass writes (unless you've asked for it, like with write
combining).
But that requirement is for the PCI bridge, isn't it? It doesn't matter if
the bridge will flush all posted writes before allowing a read if the CPU
decides to give the bridge the read before the write. A powerpc CPU will
certainly do this if you don't take any steps like telling it the memory is
uncachable and guarded. I didn't think it was allowed on x86 (except with
WC), but Nick seemed to say it was.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/