linux-kernel - Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 May 2016 06:03:20 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Waiman Long <Waiman.Long@....com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Jason Low <jason.low2@...com>,
	Dave Chinner <david@...morbit.com>,
	Scott J Norton <scott.norton@....com>,
	Douglas Hatch <doug.hatch@....com>
Subject: Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner
 field

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 <Waiman.Long@....com>

Acked-by: Davidlohr Bueso <dave@...olabs.net>