On Thu, Jun 12, 2014 at 04:54:52PM -0400, Waiman Long wrote:
If two tasks see the pending bit goes away and try to grab it with cmpxchg,
there is no way we can avoid the contention. However, if some how the
pending bit holder get the lock and another task set the pending bit before
the current
On Wed, Jun 11, 2014 at 05:22:28PM -0400, Long, Wai Man wrote:
@@ -233,11 +233,25 @@ void queue_spin_lock_slowpath(struct qspinlock *lock,
u32 val)
*/
for (;;) {
/*
-* If we observe any contention; queue.
+* If we observe that the queue is not
On 06/12/2014 02:00 AM, Peter Zijlstra wrote:
On Wed, Jun 11, 2014 at 05:22:28PM -0400, Long, Wai Man wrote:
@@ -233,11 +233,25 @@ void queue_spin_lock_slowpath(struct qspinlock *lock, u32
val)
*/
for (;;) {
/*
-* If we observe any contention;
On Fri, May 30, 2014 at 11:43:52AM -0400, Waiman Long wrote:
---
kernel/locking/qspinlock.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index fc7fd8c..7f10758 100644
---
On 6/11/2014 6:26 AM, Peter Zijlstra wrote:
On Fri, May 30, 2014 at 11:43:52AM -0400, Waiman Long wrote:
---
kernel/locking/qspinlock.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index
There is a problem in the current pending bit spinning code. When the
lock is free, but the pending bit holder hasn't grabbed the lock
cleared the pending bit yet, the spinning code will not be run.
As a result, the regular queuing code path might be used most of
the time even when there is only
