Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2985933imu; Thu, 29 Nov 2018 13:32:00 -0800 (PST) X-Google-Smtp-Source: AFSGD/WRhdWL43UG8I3Rn52jNB6HDREpqZdiq/7u2/ZdPT9b+ejVlJ114wusY5+LcmG88dTMYewX X-Received: by 2002:a63:c24c:: with SMTP id l12mr2651518pgg.146.1543527120876; Thu, 29 Nov 2018 13:32:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543527120; cv=none; d=google.com; s=arc-20160816; b=lkWPADfko0w7hGg5K+cLVQ1u3d1ebkkEXK3ARBrBkJePf0jtutHpBmsvSjjm5ua9GQ MwTpKQvBTO4XN7dafRZsZqPZlML+wqSLPYr+iB31eRCan7gjQGrnx/XGPcvLtlFSp6+a agt+z5IDLQqCV9yhWFaIVK2GFDIcVtrvCfdxCrWpFpsgR7cvHWhhnHw6zdk2w1oUyxlh q/n7xmN3e5bTiYniIJz8OFzieJvFoIUZ+qVKzUM21aVapNLDFNyVvMw4a6prrwQ7f3+t u9mhBLEs0QfI9Q6yAOSEc7PRuwNl9dhbY5yvTiJRndcXNoEHfN6GTw7CtNmNcUIadKL0 wSMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:user-agent:1;5002;0cto:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :from:date; bh=ilraRdWYU853X4nIEoLjhQMKy1ONDFytoPcc2rUvGXQ=; b=aAehtUnC1DlH07I6NmPW3PH9f9dzqcyD06Jg52H3eBdOv5yYk3KA3Z83RT48hjLI1p trzvK70z/fhulJYeGgN1r0vmLDsdPyHCU2ULHU1rNrcrgL61TKc4vXCWPikcATMHXiwj xKy77GWHzNemsV5NG3dA9/0GvCkGKbNm75CX3WzUiTT14AeaiOJZrVDWr6Ccql5PvzEX Edfh4mTLwl/RHxRFYqX8ORPcREkMvdg9opAKUszH0LsKHfh7epDf3SJEOd+YWEHEbBBm BQYcu6m308622Ah/ekoy/H+YMAXJKbZyR5xpupkLe5C5WXtI/3hN4UGGQROE+BJCR0At W/BQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 37si2537677pgw.590.2018.11.29.13.31.45; Thu, 29 Nov 2018 13:32:00 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727190AbeK3IhP (ORCPT + 99 others); Fri, 30 Nov 2018 03:37:15 -0500 Received: from mx2.suse.de ([195.135.220.15]:52086 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726555AbeK3IhO (ORCPT ); Fri, 30 Nov 2018 03:37:14 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 182D0B0D6; Thu, 29 Nov 2018 21:30:25 +0000 (UTC) Date: Thu, 29 Nov 2018 13:30:17 -0800 From: Davidlohr Bueso Cc: Peter Zijlstra , Yongji Xie , mingo@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, xieyongji@baidu.com, zhangyu31@baidu.com, liuqi16@baidu.com, yuanlinsi01@baidu.com, nixun@baidu.com, lilin24@baidu.com Subject: Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil Message-ID: <20181129213017.v3eljor54lfpoug2@linux-r8p5> References: <1543495830-2644-1-git-send-email-xieyongji@baidu.com> <20181129131232.GN2131@hirez.programming.kicks-ass.net> <5598cd71-c3c8-d6ef-eb30-777cf901a2ef@redhat.com> <20181129160627.GU2131@hirez.programming.kicks-ass.net> <8cc45695-b325-a219-8b46-d5da6ddfdd63@redhat.com> <20181129172700.GA11632@hirez.programming.kicks-ass.net> <20181129180828.GA11650@hirez.programming.kicks-ass.net> <729ceddb-dd9a-ec2a-f74e-03fa4d7e65e8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <729ceddb-dd9a-ec2a-f74e-03fa4d7e65e8@redhat.com> 1;5002;0cTo: Waiman Long User-Agent: NeoMutt/20180323 To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Nov 2018, Waiman Long wrote: >That can be costly for x86 which will now have 2 locked instructions. Yeah, and when used as an actual queue we should really start to notice. Some users just have a single task in the wake_q because avoiding the cost of wake_up_process() with locks held is significant. How about instead of adding the barrier before the cmpxchg, we do it in the failed branch, right before we return. This is the uncommon path. Thanks, Davidlohr diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 091e089063be..0d844a18a9dc 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -408,8 +408,14 @@ void wake_q_add(struct wake_q_head *head, struct task_struct *task) * This cmpxchg() executes a full barrier, which pairs with the full * barrier executed by the wakeup in wake_up_q(). */ - if (cmpxchg(&node->next, NULL, WAKE_Q_TAIL)) + if (cmpxchg(&node->next, NULL, WAKE_Q_TAIL)) { + /* + * Ensure, that when the cmpxchg() fails, the corresponding + * wake_up_q() will observe our prior state. + */ + smp_mb__after_atomic(); return; + } get_task_struct(task);