From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 474167CA3 for ; Tue, 14 Jun 2016 14:11:38 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 92D91AC005 for ; Tue, 14 Jun 2016 12:11:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) by cuda.sgi.com with ESMTP id IRSCI9F6UNcU3Qff (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 14 Jun 2016 12:11:32 -0700 (PDT) Message-ID: <576056DB.5050701@hpe.com> Date: Tue, 14 Jun 2016 15:11:23 -0400 From: Waiman Long MIME-Version: 1.0 Subject: Re: [RFC PATCH-tip 2/6] locking/rwsem: Enable optional count-based spinning on reader References: <1465927959-39719-1-git-send-email-Waiman.Long@hpe.com> <1465927959-39719-3-git-send-email-Waiman.Long@hpe.com> <20160614182757.GA15903@linux-80c1.suse> In-Reply-To: <20160614182757.GA15903@linux-80c1.suse> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Davidlohr Bueso Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org, Scott J Norton , Peter Zijlstra , x86@kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, Ingo Molnar , linux-alpha@vger.kernel.org, Douglas Hatch , Jason Low On 06/14/2016 02:27 PM, Davidlohr Bueso wrote: > On Tue, 14 Jun 2016, Waiman Long wrote: > >> This patch provides a way for the kernel code to designate specific >> rwsems to be more aggressive in term of optimistic spinning that the >> writers will continue to spin for some additional count-based time to >> see if it can get the lock before sleeping. This aggressive spinning >> mode should only be used on rwsems where the readers are unlikely to >> go to sleep. > > Yikes, exposing this sort of thing makes me _very_ uneasy, not to mention > the ad-hoc nature and its easiness to mess up. I'm not really for > this, even > if it shows extraordinary performance boosts on benchmarks. > > Thanks, > Davidlohr I understand your concern. I will see if there is a way to autotune instead of using explicit enablement. Cheers, Longman _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs