Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp199472ybm; Mon, 20 May 2019 14:33:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4kYrJSXJp8SP2gzqldpW2MFX2Cw/M8hexH0ZVUNq6PbrUqSwSY7DxM7QMpHfHEH1q3OPH X-Received: by 2002:a17:902:46a:: with SMTP id 97mr50252004ple.66.1558388001614; Mon, 20 May 2019 14:33:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558388001; cv=none; d=google.com; s=arc-20160816; b=TaQtc9BDkaOLSf9OIgjvVOuCIZauSBI3OQPd+uJt2sFKPfbUP90mU9U1JmcUkbTPwJ eBGY/xL/nkzAa+A6TD7Ml68B56H4vOZ1JKpG+PXBzkHVSbYAEm5vnXNChEqImdOHT2yL RUcPoGeeVXmBjGr/5RLxgQ3oMa3Y/xCNOrUFGhV7JwI+TrZVG8dhMAl7zcQFvpTdEY5/ JDnGpIvsNegzXwSonh4y3ly645Va6mi9a3N6h4q+GvyXzSc/xlfQtK0TXiLhwuRkFJX0 6lKJIcQS8DfwIOZx5X+JOzRT4KV16lsXfSUYfzx9hl8V1NhYkVfVgyYPrpe1bzeWSUOU Ohcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=H9sVc8DrDFnPJFpDLLFXAHpgofH8wTSoCMkzL7UdX9Y=; b=ynkyAie4uWJTWFSVU8927uvg1+Tln879Pd+OSlmzUR1z5B0zWI/h8ngK1caa/f/RdA Wt4cnrHuKUbYWYHUwcAkwxDLuctb6/7UeNp+XyxIV81plOnHs7W6p1KMXZRvs3ZH4jG8 Bj7Ig2Dg2hqsF++Ek69iKUuiws7IBb4+ri6SYpZfn629LmCmSCicfJISaxPEvzrub91j XnZPbaqb+msr+i1+9q92nNDlfkPbV46/RvNwYfpVlg7OuaPv/rBLfxBGVDyda93K//Kq CaZYKUHE/ioZ4IHNmZ2eQYpZhL1N5Iqbmx0Pg+8ADi6irxvR5bctDDkwcH10VMo+oB12 y3zQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h16si17233354plr.68.2019.05.20.14.33.06; Mon, 20 May 2019 14:33:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727043AbfETVAJ (ORCPT + 99 others); Mon, 20 May 2019 17:00:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34080 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726933AbfETVAG (ORCPT ); Mon, 20 May 2019 17:00:06 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BE1B83087939; Mon, 20 May 2019 21:00:05 +0000 (UTC) Received: from llong.com (dhcp-17-85.bos.redhat.com [10.18.17.85]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0FADD17CF3; Mon, 20 May 2019 21:00:03 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Davidlohr Bueso , Linus Torvalds , Tim Chen , huang ying , Waiman Long Subject: [PATCH v8 08/19] locking/rwsem: Always release wait_lock before waking up tasks Date: Mon, 20 May 2019 16:59:07 -0400 Message-Id: <20190520205918.22251-9-longman@redhat.com> In-Reply-To: <20190520205918.22251-1-longman@redhat.com> References: <20190520205918.22251-1-longman@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Mon, 20 May 2019 21:00:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With the use of wake_q, we can do task wakeups without holding the wait_lock. There is one exception in the rwsem code, though. It is when the writer in the slowpath detects that there are waiters ahead but the rwsem is not held by a writer. This can lead to a long wait_lock hold time especially when a large number of readers are to be woken up. Remediate this situation by releasing the wait_lock before waking up tasks and re-acquiring it afterward. The rwsem_try_write_lock() function is also modified to read the rwsem count directly to avoid stale count value. Suggested-by: Peter Zijlstra Signed-off-by: Waiman Long --- include/linux/sched/wake_q.h | 5 +++++ kernel/locking/rwsem.c | 31 +++++++++++++++---------------- 2 files changed, 20 insertions(+), 16 deletions(-) diff --git a/include/linux/sched/wake_q.h b/include/linux/sched/wake_q.h index ad826d2a4557..26a2013ac39c 100644 --- a/include/linux/sched/wake_q.h +++ b/include/linux/sched/wake_q.h @@ -51,6 +51,11 @@ static inline void wake_q_init(struct wake_q_head *head) head->lastp = &head->first; } +static inline bool wake_q_empty(struct wake_q_head *head) +{ + return head->first == WAKE_Q_TAIL; +} + extern void wake_q_add(struct wake_q_head *head, struct task_struct *task); extern void wake_q_add_safe(struct wake_q_head *head, struct task_struct *task); extern void wake_up_q(struct wake_q_head *head); diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c index 0c8aef065acb..36aed5236bd2 100644 --- a/kernel/locking/rwsem.c +++ b/kernel/locking/rwsem.c @@ -400,13 +400,14 @@ static void rwsem_mark_wake(struct rw_semaphore *sem, * If wstate is WRITER_HANDOFF, it will make sure that either the handoff * bit is set or the lock is acquired with handoff bit cleared. */ -static inline bool rwsem_try_write_lock(long count, struct rw_semaphore *sem, +static inline bool rwsem_try_write_lock(struct rw_semaphore *sem, enum writer_wait_state wstate) { - long new; + long count, new; lockdep_assert_held(&sem->wait_lock); + count = atomic_long_read(&sem->count); do { bool has_handoff = !!(count & RWSEM_FLAG_HANDOFF); @@ -751,26 +752,25 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, int state) ? RWSEM_WAKE_READERS : RWSEM_WAKE_ANY, &wake_q); - /* - * The wakeup is normally called _after_ the wait_lock - * is released, but given that we are proactively waking - * readers we can deal with the wake_q overhead as it is - * similar to releasing and taking the wait_lock again - * for attempting rwsem_try_write_lock(). - */ - wake_up_q(&wake_q); - - /* We need wake_q again below, reinitialize */ - wake_q_init(&wake_q); + if (!wake_q_empty(&wake_q)) { + /* + * We want to minimize wait_lock hold time especially + * when a large number of readers are to be woken up. + */ + raw_spin_unlock_irq(&sem->wait_lock); + wake_up_q(&wake_q); + wake_q_init(&wake_q); /* Used again, reinit */ + raw_spin_lock_irq(&sem->wait_lock); + } } else { - count = atomic_long_add_return(RWSEM_FLAG_WAITERS, &sem->count); + atomic_long_or(RWSEM_FLAG_WAITERS, &sem->count); } wait: /* wait until we successfully acquire the lock */ set_current_state(state); while (true) { - if (rwsem_try_write_lock(count, sem, wstate)) + if (rwsem_try_write_lock(sem, wstate)) break; raw_spin_unlock_irq(&sem->wait_lock); @@ -811,7 +811,6 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, int state) } raw_spin_lock_irq(&sem->wait_lock); - count = atomic_long_read(&sem->count); } __set_current_state(TASK_RUNNING); list_del(&waiter.list); -- 2.18.1