From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751870AbdB0PHx (ORCPT ); Mon, 27 Feb 2017 10:07:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45868 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751793AbdB0PHv (ORCPT ); Mon, 27 Feb 2017 10:07:51 -0500 Subject: Re: [PATCH-tip 3/3] locking/rwsem: Stop active read lock ASAP To: Davidlohr Bueso References: <1487786634-22641-1-git-send-email-longman@redhat.com> <1487786634-22641-4-git-send-email-longman@redhat.com> <20170226185816.GF5126@linux-80c1.suse> Cc: Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org From: Waiman Long Organization: Red Hat Message-ID: <6966e39f-78cf-7968-8d4a-a0a1fbe8f676@redhat.com> Date: Mon, 27 Feb 2017 10:07:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170226185816.GF5126@linux-80c1.suse> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 27 Feb 2017 15:07:46 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/26/2017 01:58 PM, Davidlohr Bueso wrote: > On Wed, 22 Feb 2017, Waiman Long wrote: > >> On a 2-socket 36-core 72-thread x86-64 E5-2699 v3 system, a rwsem >> microbenchmark was run with 36 locking threads (one/core) doing 100k >> reader and writer lock/unlock operations each, the resulting locking >> rates (avg of 3 runs) on a 4.10 kernel were 561.4 Mop/s and 588.8 >> Mop/s without and with the patch respectively. That was an increase >> of about 5%. > > iirc this patch is a repost, no? If so, did you get a chance to measure > single file access with direct io as dchinner suggested? > > Thanks, > Davidlohr Yes, this patch is a derivative of part of the rwsem reader spinning patch set that I posted before. The major change here in this patch is from the unconditional spitting into 2 atomic adds to a conditional spitting depending the on OSQ state and the ability to acquire the wait_lock immediately without waiting. This should reduce the concern that you have with the original patch. I will run a single-file direct I/O test as well. Cheers, Longman