On Fri, 2016-05-06 at 20:20 -0400, 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.l...@hpe.com>
Acked-by: Jason Low <jason.l...@hp.com>
