Re: [PATCH -tip v2 4/7] locking/mutex: Refactor optimistic spinning code

2014-07-30 Thread Jason Low
On Wed, 2014-07-30 at 13:41 -0700, Davidlohr Bueso wrote: > When we fail to acquire the mutex in the fastpath, we end up calling > __mutex_lock_common(). A *lot* goes on in this function. Move out the > optimistic spinning code into mutex_optimistic_spin() and simplify > the former a bit.

[PATCH -tip v2 4/7] locking/mutex: Refactor optimistic spinning code

2014-07-30 Thread Davidlohr Bueso
When we fail to acquire the mutex in the fastpath, we end up calling __mutex_lock_common(). A *lot* goes on in this function. Move out the optimistic spinning code into mutex_optimistic_spin() and simplify the former a bit. Furthermore, this is similar to what we have in rwsems. No logical

[PATCH -tip v2 4/7] locking/mutex: Refactor optimistic spinning code

2014-07-30 Thread Davidlohr Bueso
When we fail to acquire the mutex in the fastpath, we end up calling __mutex_lock_common(). A *lot* goes on in this function. Move out the optimistic spinning code into mutex_optimistic_spin() and simplify the former a bit. Furthermore, this is similar to what we have in rwsems. No logical

Re: [PATCH -tip v2 4/7] locking/mutex: Refactor optimistic spinning code

2014-07-30 Thread Jason Low
On Wed, 2014-07-30 at 13:41 -0700, Davidlohr Bueso wrote: When we fail to acquire the mutex in the fastpath, we end up calling __mutex_lock_common(). A *lot* goes on in this function. Move out the optimistic spinning code into mutex_optimistic_spin() and simplify the former a bit. Furthermore,