aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/util/trace-event-scripting.c
diff options
context:
space:
mode:
authorWill Deacon <[email protected]>2012-08-10 15:22:09 +0100
committerThomas Gleixner <[email protected]>2012-08-13 18:46:54 +0200
commit0bce9c46bf3b15f485d82d7e81dabed6ebcc24b1 (patch)
tree2378c052d6a19efaad21eabd58ccf8b8df489bde /tools/perf/util/trace-event-scripting.c
parent3bf671af14d591ede9251acb0085e8017f3705e7 (diff)
mutex: Place lock in contended state after fastpath_lock failure
ARM recently moved to asm-generic/mutex-xchg.h for its mutex implementation after the previous implementation was found to be missing some crucial memory barriers. However, this has revealed some problems running hackbench on SMP platforms due to the way in which the MUTEX_SPIN_ON_OWNER code operates. The symptoms are that a bunch of hackbench tasks are left waiting on an unlocked mutex and therefore never get woken up to claim it. This boils down to the following sequence of events: Task A Task B Task C Lock value 0 1 1 lock() 0 2 lock() 0 3 spin(A) 0 4 unlock() 1 5 lock() 0 6 cmpxchg(1,0) 0 7 contended() -1 8 lock() 0 9 spin(C) 0 10 unlock() 1 11 cmpxchg(1,0) 0 12 unlock() 1 At this point, the lock is unlocked, but Task B is in an uninterruptible sleep with nobody to wake it up. This patch fixes the problem by ensuring we put the lock into the contended state if we fail to acquire it on the fastpath, ensuring that any blocked waiters are woken up when the mutex is released. Signed-off-by: Will Deacon <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Chris Mason <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: <[email protected]> Reviewed-by: Nicolas Pitre <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions