On Tue, 6 Apr 2010, Jamie Lokier wrote: > > On the same subject of relying on undocumented features: > > /* If SMP and !X86_PPRO_FENCE. */ > #define smp_rmb() barrier() > > I've seen documentation, links posted to lkml ages ago, which implies > this is fine on 64-bit for both Intel and AMD. > > But it appears to be relying on undocumented behaviour on 32-bit... That memory ordering whitepaper is very much supposed to cover all the 32-bit CPU's too. The people involved were convinced that neither AMD nor Intel had ever produced anything that would do anything that broke the rules. In fact, at least the Intel "memory ordering whitepaper" doesn't even exist any more. Go to intel.com and search, and you'll find: "Intel® 64 Architecture Memory Ordering White Paper This document has been merged into Volume 3A of Intel 64 and IA-32 Architectures Software Developers Manual." which makes it pretty clear that it's not a 64-bit vs 32-bit issue. > Are you sure it is ok? Has anyone from Intel/AMD ever confirmed it is > ok? Has it been tested? Clones? No clones need apply - nobody ever did very aggressive memory re-ordering, and clones generally never did SMP either. There is a VIA chip (I think) that had some relaxed cache mode, but that needed a cr4 bit enable or similar, and since it wasn't SMP it only mattered for DMA (and possibly nontemporal stores). Anyway, it all boils down to: yes, we can depend on the memory ordering. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
