On Tue, 2013-07-30 at 21:24 +0200, Ingo Molnar wrote: > > > > Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> > > > +config RWSEM_SPIN_ON_WRITE_OWNER > > + bool "Optimistic spin write acquisition for writer owned rw-sem" > > + default n > > + depends on SMP > > + help > > + Allows a writer to perform optimistic spinning if another writer own > > + the read write semaphore. If the lock owner is running, it is likely > > + to release the lock soon. Spinning gives a greater chance for writer to > > + acquire a semaphore before putting it to sleep. > > The way you've worded this new Kconfig option makes it > sound as if it's not just for testing, and I'm not a big > believer in extra Kconfig degrees of freedom for > scalability features of core locking primitives like > rwsems, in production kernels ... > > So the bad news is that such scalability optimizations > really need to work for everyone. > > The good news is that I don't think there's anything > particularly controversial about making the rwsem write > side perform just as well as mutexes - it would in fact be > a very nice quality of implementation feature: it gives > people freedom to switch between mutexes and rwsems without > having to worry about scalability differences too much. > Sorry for replying to your email late as I was pulled to some other tasks. Ingo, any objection if I make the optimistic writer spin the default for SMP without an extra config? This will make the rw_semaphore structure grow a bit to accommodate the owner and spin_mlock field. Thanks. Tim > Once readers are mixed into the workload can we keep the > XFS assumptions, if they are broken in any way? > > We are spinning here so we have full awareness about the > state of the lock and we can react to a new reader in very > short order - so at a quick glance I don't see any > fundamental difficulty in being able to resolve it - beyond > the SMOP aspect that is ... :-) > > Thanks, > > Ingo -- 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>