[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0806110736500.3101@woody.linux-foundation.org>
Date: Wed, 11 Jun 2008 07:46:03 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nick Piggin <nickpiggin@...oo.com.au>
cc: Paul Mackerras <paulus@...ba.org>, Matthew Wilcox <matthew@....cx>,
Trent Piepho <tpiepho@...escale.com>,
Russell King <rmk+lkml@....linux.org.uk>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
David Miller <davem@...emloft.net>, linux-arch@...r.kernel.org,
scottwood@...escale.com, linuxppc-dev@...abs.org,
alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: MMIO and gcc re-ordering issue
On Wed, 11 Jun 2008, Nick Piggin wrote:
>
> I can't actually find the definitive statement in the Intel manuals
> saying UC is strongly ordered also WRT WB. Linus?
Definitive? Dunno. But look in the Architecture manual, volume 3A, 10.3
"Methods of Caching Available", and then under the bullet about Write
Combining (WC), it says
the writes may be delayed until the next occurrence of a serializing
event; such as, an SFENCE of MFENCE instruction, CPUID execution, a read
or write to uncached memory, an interrupt occurrence, or a LOCK
instruction execution.
However, it's worth noting that
- documentation can be wrong, or even if right, can be Intel-specific.
- the above is expressly _only_ about the WC buffer, not about regular
memory writes. Cached memory accesses are different from WC accesses.
so in the end, the thing that matters is how things actually work.
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