Re: Semantics of smp_mb() [was : Re: [PATCH] Fix RCU race in access of nohz_cpu_mask ]

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Thu, Mar 30, 2006 at 08:56:27PM -0800, Jeremy Higdon wrote:
> On Mon, Mar 13, 2006 at 10:39:32AM -0800, Paul E. McKenney wrote:
> > On Thu, Dec 15, 2005 at 11:46:26PM -0800, Jeremy Higdon wrote:
> > > Roland Dreier got this right.  The purpose of the mmiowb is
> > > to ensure that writes to I/O devices while holding a spinlock
> > > are ordered with respect to writes issued after the original
> > > processor releases and a second processor acquires said
> > > spinlock.
> > > 
> > > A MMIO read would be sufficient, but is much heavier weight.
> > > 
> > > On the SGI MIPS-based systems, the "sync" instruction was used.
> > > On the Altix systems, a register on the hub chip is read.
> > > 
> > > >From comments by jejb, we're looking at modifying the mmiowb
> > > API by adding an argument which would be a register to read
> > > from if the architecture in question needs ordering in this
> > > way but does not have a lighter weight mechanism like the Altix
> > > mmiowb.  Since there will now need to be a width indication,
> > > mmiowb will be replaced with mmiowb[bwlq].
> > 
> > Any progress on this front?  I figured that I would wait to update
> > the ordering document until after this change happened, but if it
> > is going to be awhile, I should proceed with the current API.
> > 
> > Thoughts?
> 
> Brent Casavant was going to be working on this.  I'll CC him so that
> he can indicate the status.

David Howells is documenting memory barriers in the Documentation
directory as well.

						Thanx, Paul
-
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/