Re: MMIO and gcc re-ordering issue

2008-06-03 Thread Jeremy Higdon
On Tue, Jun 03, 2008 at 06:19:05PM +1000, Nick Piggin wrote: On Tuesday 03 June 2008 18:15, Jeremy Higdon wrote: On Tue, Jun 03, 2008 at 02:33:11PM +1000, Nick Piggin wrote: On Monday 02 June 2008 19:56, Jes Sorensen wrote: Would we be able to use Ben's trick of setting a per cpu flag

Re: MMIO and gcc re-ordering issue

2008-06-03 Thread Jeremy Higdon
On Tue, Jun 03, 2008 at 02:33:11PM +1000, Nick Piggin wrote: On Monday 02 June 2008 19:56, Jes Sorensen wrote: Jeremy Higdon wrote: We don't actually have that problem on the Altix. All writes issued by CPU X will be ordered with respect to each other. But writes by CPU X and CPU Y

Re: MMIO and gcc re-ordering issue

2008-06-02 Thread Jeremy Higdon
On Mon, Jun 02, 2008 at 11:56:39AM +0200, Jes Sorensen wrote: Jeremy Higdon wrote: We don't actually have that problem on the Altix. All writes issued by CPU X will be ordered with respect to each other. But writes by CPU X and CPU Y will not be, unless an mmiowb() is done by the original

Re: MMIO and gcc re-ordering issue

2008-05-31 Thread Jeremy Higdon
On Thu, May 29, 2008 at 10:47:18AM -0400, Jes Sorensen wrote: Thats not going to solve the problem on Altix. On Altix the issue is that there can be multiple paths through the NUMA fabric from cpuX to PCI bridge Y. Consider this uber-cooltm ascii art - NR is my abbrevation for NUMA router:

Re: MMIO and gcc re-ordering issue

2008-05-31 Thread Jeremy Higdon
On Fri, May 30, 2008 at 10:21:00AM -0700, Jesse Barnes wrote: On Friday, May 30, 2008 2:36 am Jes Sorensen wrote: James Bottomley wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's.