From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752048AbcEJNDi (ORCPT ); Tue, 10 May 2016 09:03:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:45143 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751262AbcEJNDg (ORCPT ); Tue, 10 May 2016 09:03:36 -0400 Date: Tue, 10 May 2016 06:03:20 -0700 From: Davidlohr Bueso To: Waiman Long Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch Subject: Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field Message-ID: <20160510130319.GA18389@linux-uzut.site> References: <1462580424-40333-1-git-send-email-Waiman.Long@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1462580424-40333-1-git-send-email-Waiman.Long@hpe.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 06 May 2016, Waiman Long wrote: >Currently, it is not possible to determine for sure if a reader >owns a rwsem by looking at the content of the rwsem data structure. >This patch adds a new state RWSEM_READER_OWNED to the owner field >to indicate that readers currently own the lock. This enables us to >address the following 2 issues in the rwsem optimistic spinning code: > > 1) rwsem_can_spin_on_owner() will disallow optimistic spinning if > the owner field is NULL which can mean either the readers own > the lock or the owning writer hasn't set the owner field yet. > In the latter case, we miss the chance to do optimistic spinning. > > 2) While a writer is spinning and a reader takes the lock, the writer > will continue to spin in the main rwsem_optimistic_spin() loop as > the owner is NULL. > >Adding the new state will allow optimistic spinning to go forward as >long as the owner field is not RWSEM_READER_OWNED and the owner is >running, if set, but stop immediately when that state has been reached. > >On a 4-socket Haswell machine running on a 4.6-rc1 based kernel, the >fio test with multithreaded randrw and randwrite tests on the same >file on a XFS partition on top of a NVDIMM were run, the aggregated >bandwidths before and after the patch were as follows: > > Test BW before patch BW after patch % change > ---- --------------- -------------- -------- > randrw 988 MB/s 1192 MB/s +21% > randwrite 1513 MB/s 1623 MB/s +7.3% > >The perf profile of the rwsem_down_write_failed() function in randrw >before and after the patch were: > > 19.95% 5.88% fio [kernel.vmlinux] [k] rwsem_down_write_failed > 14.20% 1.52% fio [kernel.vmlinux] [k] rwsem_down_write_failed > >The actual CPU cycles spend in rwsem_down_write_failed() dropped from >5.88% to 1.52% after the patch. > >The xfstests was also run and no regression was observed. > >Signed-off-by: Waiman Long Acked-by: Davidlohr Bueso