On Wed, Nov 20, 2013 at 10:19:57AM +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? +1 to that! In fact, it would be nice to have the test code in-tree, especially if it can test a wide variety of locks. (/me needs to look at what test code for locks might already be in tree, for that matter...) Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>