Re: MMIO and gcc re-ordering issue
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 in > > > > writel() then and checking that in spin unlock issuing the mmiowb() > > > > there if needed? > > > > > > Yes you could, but your writels would still not be strongly ordered > > > within (or outside) spinlock regions, which is what Linus wants (and > > > I kind of agree with). > > > > Yes they would be. Writes from the same CPU are always ordered. Writes > > from different CPUs are not, but that's only a concern if you protect > > They are not strongly ordered WRT writes to cacheable memory. If they > were, then they would not leak out of spinlocks. No posted writes are. As I recall, the outX functions are not supposed to be posted, so the sn2 versions issue a mmiowb in the outX. But writeX has always been posted, or at least postable. I thought that was generally accepted. Normally, the only way for a device to see cacheable memory is via a DMA read, and you are guaranteed on sn2 that in the following: store of of A to location X mmio write to device device DMA read from location X that the device will see A. In the past, on some other archs, you'd have to flush the Dcache for that to work. Granted, if the compiler reorders the store and the mmio write, then you have a problem. jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
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 will not be, unless an mmiowb() is done by the > > > original CPU before the second CPU writes. I.e. > > > > > > CPU X writel > > > CPU X writel > > > CPU X mmiowb > > > > > > CPU Y writel > > > ... > > > > > > Note that this implies some sort of locking. Also note that if in > > > the above, CPU Y did the mmiowb, that would not work. > > > > Hmmm, > > > > Then it's less bad than I thought - my apologies for the confusion. > > > > Would we be able to use Ben's trick of setting a per cpu flag in > > writel() then and checking that in spin unlock issuing the mmiowb() > > there if needed? > > Yes you could, but your writels would still not be strongly ordered > within (or outside) spinlock regions, which is what Linus wants (and > I kind of agree with). Yes they would be. Writes from the same CPU are always ordered. Writes from different CPUs are not, but that's only a concern if you protect writing via some sort of lock. If the lock release forces a barrier, that should take care of the problem. jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
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 CPU before the second CPU writes. I.e. > > > > CPU X writel > > CPU X writel > > CPU X mmiowb > > > > CPU Y writel > > ... > > > >Note that this implies some sort of locking. Also note that if in > >the above, CPU Y did the mmiowb, that would not work. > > Hmmm, > > Then it's less bad than I thought - my apologies for the confusion. > > Would we be able to use Ben's trick of setting a per cpu flag in > writel() then and checking that in spin unlock issuing the mmiowb() > there if needed? Yes, that should work fine. You will get more mmiowb's than you need, since some drivers, such as Fusion, don't need them. On the Origins (older SGI MIPS-based Numa), the 'sync' instruction had the same effect as mmiowb() with respect to mmio write ordering, and it was issued unconditionally in the spin unlock. It was cheaper than mmiowb, however. If it matters, we could invent and use writel_relaxed() to get performance back in drivers we care about jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
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. On Altix you have to go and read from the PCI brige to > > >> ensure all writes to it have been flushed, which is also what mmiowb() > > >> is doing. If writel() was to guarantee this ordering, it would make > > >> every writel() call extremely expensive :-( > > > > > > So if a read from the bridge achieves the same effect, can't we just put > > > one after the writes within the spinlock (an unrelaxed one). That way A relaxed readX would be sufficient. It's the next lowest cost way (after mmiowb) of ensuring write ordering between CPUs. Regular readX is the most expensive method (well, we could probably come up with something worse, but we'd have to work at it :). > > > this whole sequence will look like a well understood PCI posting flush > > > rather than have to muck around with little understood (at least by most > > > driver writers) io barriers? > > > > Hmmm, > > > > I think mmiowb() does some sort of status read from the bridge, I am not > > sure if it's enough to just do a regular readl(). > > > > I'm adding Jeremy to the list, he should know for sure. > > I think a read from the target host bridge is enough. What mmiowb() does > though is to read a *local* host bridge register, which contains a count of > the number of PIO ops still "in flight" on their way to their target bridge. > When it reaches 0, all PIOs have arrived at the target host bridge (they > still may be bufferd), so ordering is guaranteed. Note that is the main advantage over a read. There is no round trip across the NUMA fabric. jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
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-cool ascii art - NR is my abbrevation for NUMA > router: > > --- --- > |cpu X| |cpu Y| > --- --- > | \ /| > |\/ | > |/\ | > | / \| > - -- > |NR 1| |NR 2| > -- -- > \ / >\ / > --- > | PCI | > --- > > The problem is that your two writel's, despite being both issued on > cpu X, due to the spin lock, in your example, can end up with the > first one going through NR 1 and the second one going through NR 2. If > there's contention on NR 1, the write going via NR 2 may hit the PCI > bridge prior to the one going via NR 1. 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 CPU before the second CPU writes. I.e. CPU X writel CPU X writel CPU X mmiowb CPU Y writel ... Note that this implies some sort of locking. Also note that if in the above, CPU Y did the mmiowb, that would not work. jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
