Re: [PATCH v6 0/5] MCS Lock: MCS lock code cleanup and optimizations

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

On Wed, Nov 20, 2013 at 09:00:47AM -0800, Tim Chen wrote:
> On Wed, 2013-11-20 at 10:19 +0000, Will Deacon wrote:
> > Hi Tim,
> > 
> > On Wed, Nov 20, 2013 at 01:37:26AM +0000, Tim Chen wrote:
> > > In this patch series, we separated out the MCS lock code which was
> > > previously embedded in the mutex.c.  This allows for easier reuse of
> > > MCS lock in other places like rwsem and qrwlock.  We also did some micro
> > > optimizations and barrier cleanup.  
> > > 
> > > The original code has potential leaks between critical sections, which
> > > was not a problem when MCS was embedded within the mutex but needs
> > > to be corrected when allowing the MCS lock to be used by itself for
> > > other locking purposes. 
> > > 
> > > Proper barriers are now embedded with the usage of smp_load_acquire() in
> > > mcs_spin_lock() and smp_store_release() in mcs_spin_unlock.  See
> > > http://marc.info/?l=linux-arch&m=138386254111507 for info on the
> > > new smp_load_acquire() and smp_store_release() functions. 
> > > 
> > > This patches were previously part of the rwsem optimization patch series
> > > but now we spearate them out.
> > > 
> > > We have also added hooks to allow for architecture specific 
> > > implementation of the mcs_spin_lock and mcs_spin_unlock functions.
> > > 
> > > Will, do you want to take a crack at adding implementation for ARM
> > > with wfe instruction?
> > 
> > Sure, I'll have a go this week. Thanks for keeping that as a consideration!
> > 
> > As an aside: what are you using to test this code, so that I can make sure I
> > don't break it?
> 
> I was testing it against my rwsem patches.  But any workload that 
> exercises mutex should also use this code, as this is part of mutex.

It would be good to have more focused tests.  It is amazing how reliable
broken synchronization-primitive implementations can be.  Of course, in
this case, they will fail at the least opportune and most difficult to
debug situation...

							Thanx, Paul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>