From patchwork Wed Apr 11 19:34:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Waiman Long X-Patchwork-Id: 10336979 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9A26B6020F for ; Wed, 11 Apr 2018 19:34:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8441327F8F for ; Wed, 11 Apr 2018 19:34:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 77D1E28173; Wed, 11 Apr 2018 19:34:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D05FE27F8F for ; Wed, 11 Apr 2018 19:34:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gPcmUo0kbu91FWU3aO/tqeA3+mZe+W5OpJ+CBPP8NtU=; b=EHh2r7IEX3LIAM GdyA950qF9qrbBToopP+ju9kxEZ+9rS+JWaFs6fXzaAJudg8mnDO3tUDmFKxiziuwNHtTWv+9YrrZ b6W8Msg0EuxZDZfkGQ6X6arw0YeiJ6jcyYxa2b8R3Zey7ve2heRKZNdsULejYfJ6ateUuKBR39exL Zq7VGFMFM8hsfsL21tn2In1CUhBE6DXGRMQcy3JrBySGtShmoRUYIvzaAtwe+C+UGXzob7WssjIRC j8R9RvuOSHwh5ZCZOcEoFwRv6Pz5DfV3HM4gS3f/tbRVo8PwUQa0cm7gZ3NHEH/EgQvalyu/MlnrU y1d2oMs+Te9y6OMQKwgg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1f6LVx-0003Sf-GB; Wed, 11 Apr 2018 19:34:41 +0000 Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f6LVt-0003R3-DO for linux-arm-kernel@lists.infradead.org; Wed, 11 Apr 2018 19:34:39 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 25F0C41662E0; Wed, 11 Apr 2018 19:34:26 +0000 (UTC) Received: from llong.remote.csb (ovpn-124-13.rdu2.redhat.com [10.10.124.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id B54641208F73; Wed, 11 Apr 2018 19:34:25 +0000 (UTC) Subject: Re: [PATCH v2 04/13] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath To: Will Deacon , linux-kernel@vger.kernel.org References: <1523469680-17699-1-git-send-email-will.deacon@arm.com> <1523469680-17699-5-git-send-email-will.deacon@arm.com> From: Waiman Long Organization: Red Hat Message-ID: <674fd9c0-e3f3-9ae0-dd0a-7ccc085c1706@redhat.com> Date: Wed, 11 Apr 2018 15:34:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1523469680-17699-5-git-send-email-will.deacon@arm.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 11 Apr 2018 19:34:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 11 Apr 2018 19:34:26 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'longman@redhat.com' RCPT:'' X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180411_123437_600107_E63F4688 X-CRM114-Status: GOOD ( 34.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peterz@infradead.org, boqun.feng@gmail.com, paulmck@linux.vnet.ibm.com, mingo@kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 04/11/2018 02:01 PM, Will Deacon wrote: > The qspinlock locking slowpath utilises a "pending" bit as a simple form > of an embedded test-and-set lock that can avoid the overhead of explicit > queuing in cases where the lock is held but uncontended. This bit is > managed using a cmpxchg loop which tries to transition the uncontended > lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1). > > Unfortunately, the cmpxchg loop is unbounded and lockers can be starved > indefinitely if the lock word is seen to oscillate between unlocked > (0,0,0) and locked (0,0,1). This could happen if concurrent lockers are > able to take the lock in the cmpxchg loop without queuing and pass it > around amongst themselves. > > This patch fixes the problem by unconditionally setting _Q_PENDING_VAL > using atomic_fetch_or, and then inspecting the old value to see whether > we need to spin on the current lock owner, or whether we now effectively > hold the lock. The tricky scenario is when concurrent lockers end up > queuing on the lock and the lock becomes available, causing us to see > a lockword of (n,0,0). With pending now set, simply queuing could lead > to deadlock as the head of the queue may not have observed the pending > flag being cleared. Conversely, if the head of the queue did observe > pending being cleared, then it could transition the lock from (n,0,0) -> > (0,0,1) meaning that any attempt to "undo" our setting of the pending > bit could race with a concurrent locker trying to set it. > > We handle this race by preserving the pending bit when taking the lock > after reaching the head of the queue and leaving the tail entry intact > if we saw pending set, because we know that the tail is going to be > updated shortly. > > Cc: Peter Zijlstra > Cc: Ingo Molnar > Signed-off-by: Will Deacon > --- > kernel/locking/qspinlock.c | 102 ++++++++++++++++++++++++++------------------- > 1 file changed, 58 insertions(+), 44 deletions(-) > > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c > index 396701e8c62d..a8fc402b3f3a 100644 > --- a/kernel/locking/qspinlock.c > +++ b/kernel/locking/qspinlock.c > @@ -162,6 +162,17 @@ struct __qspinlock { > > #if _Q_PENDING_BITS == 8 > /** > + * clear_pending - clear the pending bit. > + * @lock: Pointer to queued spinlock structure > + * > + * *,1,* -> *,0,* > + */ > +static __always_inline void clear_pending(struct qspinlock *lock) > +{ > + WRITE_ONCE(lock->pending, 0); > +} > + > +/** > * clear_pending_set_locked - take ownership and clear the pending bit. > * @lock: Pointer to queued spinlock structure > * > @@ -201,6 +212,17 @@ static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail) > #else /* _Q_PENDING_BITS == 8 */ > > /** > + * clear_pending - clear the pending bit. > + * @lock: Pointer to queued spinlock structure > + * > + * *,1,* -> *,0,* > + */ > +static __always_inline void clear_pending(struct qspinlock *lock) > +{ > + atomic_andnot(_Q_PENDING_VAL, &lock->val); > +} > + > +/** > * clear_pending_set_locked - take ownership and clear the pending bit. > * @lock: Pointer to queued spinlock structure > * > @@ -306,7 +328,7 @@ static __always_inline u32 __pv_wait_head_or_lock(struct qspinlock *lock, > void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) > { > struct mcs_spinlock *prev, *next, *node; > - u32 new, old, tail; > + u32 old, tail; > int idx; > > BUILD_BUG_ON(CONFIG_NR_CPUS >= (1U << _Q_TAIL_CPU_BITS)); > @@ -330,58 +352,50 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) > } > > /* > + * If we observe any contention; queue. > + */ > + if (val & ~_Q_LOCKED_MASK) > + goto queue; > + > + /* > * trylock || pending > * > * 0,0,0 -> 0,0,1 ; trylock > * 0,0,1 -> 0,1,1 ; pending > */ > - for (;;) { > + val = atomic_fetch_or_acquire(_Q_PENDING_VAL, &lock->val); > + if (!(val & ~_Q_LOCKED_MASK)) { > /* > - * If we observe any contention; queue. > + * we're pending, wait for the owner to go away. > + * > + * *,1,1 -> *,1,0 > + * > + * this wait loop must be a load-acquire such that we match the > + * store-release that clears the locked bit and create lock > + * sequentiality; this is because not all > + * clear_pending_set_locked() implementations imply full > + * barriers. > */ > - if (val & ~_Q_LOCKED_MASK) > - goto queue; > - > - new = _Q_LOCKED_VAL; > - if (val == new) > - new |= _Q_PENDING_VAL; > + if (val & _Q_LOCKED_MASK) { > + smp_cond_load_acquire(&lock->val.counter, > + !(VAL & _Q_LOCKED_MASK)); > + } > > /* > - * Acquire semantic is required here as the function may > - * return immediately if the lock was free. > + * take ownership and clear the pending bit. > + * > + * *,1,0 -> *,0,1 > */ > - old = atomic_cmpxchg_acquire(&lock->val, val, new); > - if (old == val) > - break; > - > - val = old; > - } > - > - /* > - * we won the trylock > - */ > - if (new == _Q_LOCKED_VAL) > + clear_pending_set_locked(lock); > return; > + } > > /* > - * we're pending, wait for the owner to go away. > - * > - * *,1,1 -> *,1,0 > - * > - * this wait loop must be a load-acquire such that we match the > - * store-release that clears the locked bit and create lock > - * sequentiality; this is because not all clear_pending_set_locked() > - * implementations imply full barriers. > - */ > - smp_cond_load_acquire(&lock->val.counter, !(VAL & _Q_LOCKED_MASK)); > - > - /* > - * take ownership and clear the pending bit. > - * > - * *,1,0 -> *,0,1 > + * If pending was clear but there are waiters in the queue, then > + * we need to undo our setting of pending before we queue ourselves. > */ > - clear_pending_set_locked(lock); > - return; > + if (!(val & _Q_PENDING_MASK)) > + clear_pending(lock); > > /* > * End of pending bit optimistic spinning and beginning of MCS > @@ -485,15 +499,15 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) > * claim the lock: > * > * n,0,0 -> 0,0,1 : lock, uncontended > - * *,0,0 -> *,0,1 : lock, contended > + * *,*,0 -> *,*,1 : lock, contended > * > - * If the queue head is the only one in the queue (lock value == tail), > - * clear the tail code and grab the lock. Otherwise, we only need > - * to grab the lock. > + * If the queue head is the only one in the queue (lock value == tail) > + * and nobody is pending, clear the tail code and grab the lock. > + * Otherwise, we only need to grab the lock. > */ > for (;;) { > /* In the PV case we might already have _Q_LOCKED_VAL set */ > - if ((val & _Q_TAIL_MASK) != tail) { > + if ((val & _Q_TAIL_MASK) != tail || (val & _Q_PENDING_MASK)) { > set_locked(lock); > break; > } I don't think it is right to just grab the lock when the pending bit is set. I believe it will cause problem. Preserving the the pending bit should be just goto release; /* No contention */ Cheers, Longman diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c index 35367cc..76d9124 100644 --- a/kernel/locking/qspinlock.c +++ b/kernel/locking/qspinlock.c @@ -511,7 +511,8 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 v * necessary acquire semantics required for locking. At most * two iterations of this loop may be ran. */ - old = atomic_cmpxchg_relaxed(&lock->val, val, _Q_LOCKED_VAL); + old = atomic_cmpxchg_relaxed(&lock->val, val, + _Q_LOCKED_VAL | (val & _Q_PENDING_MASK)); if (old == val)