From: Peter Zijlstra <peterz@infradead.org>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Alex Shi <alex.shi@linaro.org>, Andi Kleen <andi@firstfloor.org>,
Michel Lespinasse <walken@google.com>,
Rik van Riel <riel@redhat.com>,
Peter Hurley <peter@hurleysoftware.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E.McKenney" <paulmck@linux.vnet.ibm.com>,
Aswin Chandramouleeswaran <aswin@hp.com>,
"Norton, Scott J" <scott.norton@hp.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rwsem: Support optimistic spinning
Date: Wed, 30 Apr 2014 12:00:47 +0200 [thread overview]
Message-ID: <20140430100047.GE11096@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1398722941.25549.16.camel@buesod1.americas.hpqcorp.net>
On Mon, Apr 28, 2014 at 03:09:01PM -0700, Davidlohr Bueso wrote:
> __visible
> struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
> {
> - long count, adjustment = -RWSEM_ACTIVE_WRITE_BIAS;
> + long count;
> struct rwsem_waiter waiter;
> struct task_struct *tsk = current;
> + bool waiting = true;
> +
> + /* undo write bias from down_write operation, stop active locking */
> + count = rwsem_atomic_update(-RWSEM_ACTIVE_WRITE_BIAS, sem);
> +
> + /* do optimistic spinning and steal lock if possible */
> + if (rwsem_optimistic_spin(sem))
> + goto done;
Why done, why not return? Afaict there's not yet been a change to the
state.
>
> /* set up my own style of waitqueue */
> waiter.task = tsk;
> @@ -204,34 +382,29 @@ struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
>
> raw_spin_lock_irq(&sem->wait_lock);
> if (list_empty(&sem->wait_list))
> - adjustment += RWSEM_WAITING_BIAS;
> + waiting = false;
> list_add_tail(&waiter.list, &sem->wait_list);
>
> /* we're now waiting on the lock, but no longer actively locking */
> - count = rwsem_atomic_update(adjustment, sem);
> + if (waiting)
> + count = ACCESS_ONCE(sem->count);
> + else
> + count = rwsem_atomic_update(RWSEM_WAITING_BIAS, sem);
> +
Is there a reason we must delay this? Why not do away with the waiting
variable and do it where we check the list_empty() ?
If there is a reason -- eg. we must order the list op vs the count op,
then there's a comment missing.
> - /* If there were already threads queued before us and there are no
> + /*
> + * If there were already threads queued before us and there are no
> * active writers, the lock must be read owned; so we try to wake
> - * any read locks that were queued ahead of us. */
> - if (count > RWSEM_WAITING_BIAS &&
> - adjustment == -RWSEM_ACTIVE_WRITE_BIAS)
> + * any read locks that were queued ahead of us.
> + */
> + if ((count > RWSEM_WAITING_BIAS) && waiting)
> sem = __rwsem_do_wake(sem, RWSEM_WAKE_READERS);
>
> /* wait until we successfully acquire the lock */
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
We should really use set_current_state(), there is no way tsk is
anything other than current, and using set_task_state() implies we're
changing someone else's state.
> while (true) {
> - if (!(count & RWSEM_ACTIVE_MASK)) {
> - /* Try acquiring the write lock. */
> - count = RWSEM_ACTIVE_WRITE_BIAS;
> - if (!list_is_singular(&sem->wait_list))
> - count += RWSEM_WAITING_BIAS;
> -
> - if (sem->count == RWSEM_WAITING_BIAS &&
> - cmpxchg(&sem->count, RWSEM_WAITING_BIAS, count) ==
> - RWSEM_WAITING_BIAS)
> - break;
> - }
> -
> + if (rwsem_try_write_lock(count, sem))
> + break;
> raw_spin_unlock_irq(&sem->wait_lock);
>
> /* Block until there are no active lockers. */
> @@ -245,8 +418,8 @@ struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
>
> list_del(&waiter.list);
> raw_spin_unlock_irq(&sem->wait_lock);
> +done:
> tsk->state = TASK_RUNNING;
__set_current_state(TASK_RUNNING);
Also, I would really expect this to be done right after the wait loop,
not outside of the lock.
> -
> return sem;
> }
Otherwise this looks ok I suppose.
next prev parent reply other threads:[~2014-04-30 10:01 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 22:19 [PATCH] rwsem: Support optimistic spinning Davidlohr Bueso
2014-04-28 5:19 ` Davidlohr Bueso
2014-04-28 7:52 ` Peter Zijlstra
2014-04-28 17:18 ` Davidlohr Bueso
2014-04-28 22:09 ` [PATCH v2] " Davidlohr Bueso
2014-04-28 23:10 ` Paul E. McKenney
2014-04-29 0:50 ` Tim Chen
2014-04-29 3:05 ` Davidlohr Bueso
2014-04-29 15:11 ` Paul E. McKenney
2014-04-29 16:00 ` Tim Chen
2014-06-04 17:57 ` Andev
2014-06-04 19:44 ` Davidlohr Bueso
2014-04-30 8:01 ` Peter Zijlstra
2014-04-30 8:27 ` Peter Zijlstra
2014-04-30 16:17 ` Davidlohr Bueso
2014-04-30 17:50 ` Tim Chen
2014-04-30 18:04 ` Peter Zijlstra
2014-04-30 18:08 ` Tim Chen
2014-04-30 21:01 ` Tim Chen
2014-04-30 21:06 ` Davidlohr Bueso
2014-04-30 21:28 ` Tim Chen
2014-04-30 9:04 ` Peter Zijlstra
2014-04-30 16:33 ` Jason Low
2014-04-30 16:50 ` Peter Zijlstra
2014-04-30 9:14 ` Peter Zijlstra
2014-04-30 16:23 ` Davidlohr Bueso
2014-04-30 9:21 ` Peter Zijlstra
2014-04-30 16:32 ` Davidlohr Bueso
2014-04-30 16:37 ` Peter Zijlstra
2014-04-30 10:00 ` Peter Zijlstra [this message]
2014-04-30 16:42 ` Davidlohr Bueso
2014-05-01 3:21 ` [PATCH v3] " Davidlohr Bueso
2014-05-01 16:39 ` Tim Chen
2014-05-01 20:32 ` Jason Low
2014-05-02 18:24 ` [PATCH v4] " Davidlohr Bueso
2014-05-19 13:12 ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2014-05-19 21:47 ` Davidlohr Bueso
2014-05-19 22:39 ` Davidlohr Bueso
2014-05-19 23:14 ` Jason Low
2014-05-20 0:27 ` Davidlohr Bueso
2014-05-20 0:54 ` [tip:locking/core] rwsem: Fix warnings for CONFIG_RWSEM_GENERIC_SPINLOCK tip-bot for Davidlohr Bueso
2014-06-05 14:32 ` [tip:locking/core] locking/rwsem: " tip-bot for Davidlohr Bueso
2014-06-05 8:38 ` [PATCH v4] rwsem: Support optimistic spinning Ingo Molnar
2014-06-05 16:03 ` Tim Chen
2014-06-05 14:32 ` [tip:locking/core] locking/rwsem: " tip-bot for Davidlohr Bueso
2014-05-14 15:01 ` [PATCH v5] rwsem: " Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140430100047.GE11096@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@linaro.org \
--cc=andi@firstfloor.org \
--cc=aswin@hp.com \
--cc=davidlohr@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peter@hurleysoftware.com \
--cc=riel@redhat.com \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=walken@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox