Date: Tue, 07 Mar 2006 19:10:00 -0600
From: Robert Hancock <hancockr@shaw.ca>
Subject: Re: [PATCH] Document Linux's memory barriers
In-reply-to: <5NUSF-30Z-5@gated-at.bofh.it>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Message-id: <440E2EE8.10708@shaw.ca>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <5NONi-2hp-3@gated-at.bofh.it> <5NQ2U-462-29@gated-at.bofh.it>
 <5NRLg-6LJ-31@gated-at.bofh.it> <5NRUR-6Yo-11@gated-at.bofh.it>
 <5NUSF-30Z-5@gated-at.bofh.it>
User-Agent: Thunderbird 1.5 (Windows/20051201)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1031
Lines: 25

Alan Cox wrote:
> On Maw, 2006-03-07 at 22:24 +0100, Andi Kleen wrote:
>>> But on most arches those accesses do indeed seem to happen in-order.  On
>>> i386 and x86_64, it's a natural consequence of program store ordering.
>> Not true for reads on x86.
> 
> You must have a strange kernel Andi. Mine marks them as volatile
> unsigned char * references.

Well, that and the fact that IO memory should be mapped as uncacheable 
in the MTRRs should ensure that readl and writel won't be reordered on 
i386 and x86_64.. except in the case where CONFIG_UNORDERED_IO is 
enabled on x86_64 which can reorder writes since it uses nontemporal 
stores..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/