linux-toradex.git/Documentation/locking, branch v3.18-rc6

Merge branch 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-10-13T13:51:40+00:00

Pull core locking updates from Ingo Molnar:
 "The main updates in this cycle were:

   - mutex MCS refactoring finishing touches: improve comments, refactor
     and clean up code, reduce debug data structure footprint, etc.

   - qrwlock finishing touches: remove old code, self-test updates.

   - small rwsem optimization

   - various smaller fixes/cleanups"

* 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/lockdep: Revert qrwlock recusive stuff
  locking/rwsem: Avoid double checking before try acquiring write lock
  locking/rwsem: Move EXPORT_SYMBOL() lines to follow function definition
  locking/rwlock, x86: Delete unused asm/rwlock.h and rwlock.S
  locking/rwlock, x86: Clean up asm/spinlock*.h to remove old rwlock code
  locking/semaphore: Resolve some shadow warnings
  locking/selftest: Support queued rwlock
  locking/lockdep: Restrict the use of recursive read_lock() with qrwlock
  locking/spinlocks: Always evaluate the second argument of spin_lock_nested()
  locking/Documentation: Update locking/mutex-design.txt disadvantages
  locking/Documentation: Move locking related docs into Documentation/locking/
  locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate
  locking/mutexes: Refactor optimistic spinning code
  locking/mcs: Remove obsolete comment
  locking/mutexes: Document quick lock release when unlocking
  locking/mutexes: Standardize arguments in lock/unlock slowpaths
  locking: Remove deprecated smp_mb__() barriers

locktorture: Support rwlocks

2014-09-30T07:10:00+00:00

Add a "rw_lock" torture test to stress kernel rwlocks and their irq
variant. Reader critical regions are 5x longer than writers. As such
a similar ratio of lock acquisitions is seen in the statistics. In the
case of massive contention, both hold the lock for 1/10 of a second.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Support rwsems

2014-09-16T20:41:36+00:00

We can easily do so with our new reader lock support. Just an arbitrary
design default: readers have higher (5x) critical region latencies than
writers: 50 ms and 10 ms, respectively.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Add infrastructure for torturing read locks

2014-09-16T20:41:07+00:00

Most of it is based on what we already have for writers. This allows
readers to be very independent (and thus configurable), enabling
future module parameters to control things such as rw distribution.
Furthermore, readers have their own delaying function, allowing us
to test different rw critical region latencies, and stress locking
internals. Similarly, statistics, for now will only serve for the
number of lock acquisitions -- as opposed to writers, readers have
no failure detection.

In addition, introduce a new nreaders_stress module parameter. The
default number of readers will be the same number of writers threads.
Writer threads are interleaved with readers. Documentation is updated,
respectively.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Support mutexes

2014-09-16T20:40:59+00:00

Add a "mutex_lock" torture test. The main difference with the already
existing spinlock tests is that the latency of the critical region
is much larger. We randomly delay for (arbitrarily) either 500 ms or,
otherwise, 25 ms. While this can considerably reduce the amount of
writes compared to non blocking locks, if run long enough it can have
the same torturous effect. Furthermore it is more representative of
mutex hold times and can stress better things like thrashing.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney

locktorture: Add documentation

2014-09-16T20:39:13+00:00

Just like Documentation/RCU/torture.txt, begin a document for the
locktorture module. This module is still pretty green, so I have
just added some specific sections to the doc (general desc, params,
usage, etc.). Further development should update the file.

Signed-off-by: Davidlohr Bueso 
[ paulmck: Apply Randy Dunlap review comments. ]
Signed-off-by: Paul E. McKenney

locking/Documentation: Update locking/mutex-design.txt disadvantages

2014-08-13T08:32:04+00:00

Fortunately Jason was able to reduce some of the overhead we
had introduced in the original rwsem optimistic spinning -
an it is now the same size as mutexes. Update the documentation
accordingly.

Signed-off-by: Davidlohr Bueso 
Acked-by: Jason Low 
Signed-off-by: Peter Zijlstra 
Cc: aswin@hp.com
Cc: Linus Torvalds 
Cc: Randy Dunlap 
Link: http://lkml.kernel.org/r/1406752916-3341-7-git-send-email-davidlohr@hp.com
Signed-off-by: Ingo Molnar

locking/Documentation: Move locking related docs into Documentation/locking/

2014-08-13T08:32:03+00:00

Specifically:
  Documentation/locking/lockdep-design.txt
  Documentation/locking/lockstat.txt
  Documentation/locking/mutex-design.txt
  Documentation/locking/rt-mutex-design.txt
  Documentation/locking/rt-mutex.txt
  Documentation/locking/spinlocks.txt
  Documentation/locking/ww-mutex-design.txt

Signed-off-by: Davidlohr Bueso 
Acked-by: Randy Dunlap 
Signed-off-by: Peter Zijlstra 
Cc: jason.low2@hp.com
Cc: aswin@hp.com
Cc: Alexei Starovoitov 
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Chris Mason 
Cc: Dan Streetman 
Cc: David Airlie 
Cc: Davidlohr Bueso 
Cc: David S. Miller 
Cc: Greg Kroah-Hartman 
Cc: Heiko Carstens 
Cc: Jason Low 
Cc: Josef Bacik 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Lubomir Rintel 
Cc: Masanari Iida 
Cc: Paul E. McKenney 
Cc: Randy Dunlap 
Cc: Tim Chen 
Cc: Vineet Gupta 
Cc: fengguang.wu@intel.com
Link: http://lkml.kernel.org/r/1406752916-3341-6-git-send-email-davidlohr@hp.com
Signed-off-by: Ingo Molnar