From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753230AbcFOTSH (ORCPT ); Wed, 15 Jun 2016 15:18:07 -0400 Received: from mail-bl2on0111.outbound.protection.outlook.com ([65.55.169.111]:23168 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932321AbcFOTSB (ORCPT ); Wed, 15 Jun 2016 15:18:01 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=waiman.long@hpe.com; Message-ID: <5761A9DE.6040702@hpe.com> Date: Wed, 15 Jun 2016 15:17:50 -0400 From: Waiman Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Peter Zijlstra CC: Ingo Molnar , , , , , , , Davidlohr Bueso , Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch Subject: Re: [RFC PATCH-tip v2 2/6] locking/rwsem: Stop active read lock ASAP References: <1465944489-43440-1-git-send-email-Waiman.Long@hpe.com> <1465944489-43440-3-git-send-email-Waiman.Long@hpe.com> <20160615172242.GQ30921@twins.programming.kicks-ass.net> In-Reply-To: <20160615172242.GQ30921@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [71.168.64.62] X-ClientProxiedBy: CY1PR12CA0057.namprd12.prod.outlook.com (10.163.230.25) To TU4PR84MB0319.NAMPRD84.PROD.OUTLOOK.COM (10.162.186.29) X-MS-Office365-Filtering-Correlation-Id: 8e5a60b2-acb2-4a6f-8874-08d39551c19e X-Microsoft-Exchange-Diagnostics: 1;TU4PR84MB0319;2:igwFmJJrpAFXN7e+l42MjQMkcHqNq5GkCmRPtRHyCSswY0Lda0ukFB9RYQ6SNkHqVexcQ1uQb8acxCxChFTdBb0yD7fkeREbBt4FCXr6E66qakiOKk3ViL61CceIIqdwLa4l2T+JhO8UFtAYFaqgct29aYOdFHCd1Sk/kSpCPkYaffgxoUuPANRlMrCAsOik;3:FmITHgN7D58sMXPWEnY3mQv1r2+K2oFYeaZ6ITkms3e2WcJon5JRwK9u/Ybkwpg63JpHPhMmlCbEcvOLgAzGwBZLwU77hHw9shWebRipEkhJIldq2OBflXpjr8nJW1T1;25:aeTMNFlntkN4NQw1NrPfKhO7sDl0PdcIxEcbgweF56SSg8wTagt9hrdCgSkZkWwQTArgo+YltT809ylptXK2ttGcvcQc4IODBDLCYvR1MqMW6AkMZU5TxmKAwy68tb8qVc07v+8mjYq63BE6rJz3tQnlxjMy9NNMSlEWnsVYVK/ilQ7J/brgMtutLoJWqvsaK8By9z8/0MB6SJgkK9oj3h5AVTcU+5EBbBUnM84iYf6DjSvA1/Ny2rWhhoS8S/O5DTUrhIS5u73vdSkW05c+TtVzblwDrq4xiBVPKSjKwLJMtaBUyBpVhz9Kl7xxmP6nZ54ZOqM65jleRvzw+vF8dKF58S62XUBe/DEPWZByoGm/nhnwl42vgNh4WaDLfB0C2sQigM+2hvea9g64z5okaODSHq50lsObeoizoKzlSSQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TU4PR84MB0319; X-Microsoft-Exchange-Diagnostics: 1;TU4PR84MB0319;20:fzHNCCBYJW3XP6T9/59+QIw3g99ep9wJ16ATgmgnmVhstjxYbQEXxFpKdLyzdTg64ShTkXFDoyxoyxgN4Cm3zPH/KbB8FvJYUS4vgjgRIK/t9YAK7e8YJ3gp0+pWEWt0D1gdeJhvO73nHpMy+L9L7Y8jput1IoIKyNJT6SX9Q78ccUWKFrDG+8L8uhYhRRJf5rFaMHgXLbpSLjSnxPhyg17lS+b64Zde1DsSU2ZKJJw4xWH5dNx041Amo+g9stg3+m0tfnrLZkCNTK/kBPH6xDW1XxI/s2aeh5nyEtjThjeez2rSwFzT4whgfOKNetGPjvY5eC8qz271K8j27OLL3uf8LAwasIKjRqYIqYlMiiPx6RZOJMqXNIAMMNwHCSiJnbJAS4wWKHoAu1ZowFQeOTDD0JtS6rbI0dtkiIvSF+JAT14sfSj6z99YkZXRyIXdkAZMvmeDKRuMe2cHRz/NQVBo5swpMPaEd/HRCS2cuPZRzh65QmKkw4uuZJwZRYdE;4:0AJBfV2wkKG8MyE0bIR/qPStvow9fug/H1bUjfIBkrFx8lcDOF7OcMOxTwNO7eBwruv4BIa4lNcMj7h8mkgK5Ukc8TVh7Yv7PjhNjKp4kh+vCwqjWUAX2KgjymOulNa/LC+U8/7Znb3sZvo6bNQzUfooGbK9m3y3GCSweYBl1wkkr1PGRt9AJhVL41JtDFrewj6R1kBhMhOLzuSecwP0so5mRsBQYiJMonIvLkmeO8UIfdDxeuJTIUE6lZ2B1HpRLsS/QMaplQTQclBuMzeLyNnSg5fmDnGJyd8Jph6b/UI9Wx+3aToUEGaA9SC2Ol74KmJ4Xw90d3zoVGjxxuqSn+qu6kmBpMucLLPqoQ/96eFNIIDWpaIBtvMpL3rV9PLG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:TU4PR84MB0319;BCL:0;PCL:0;RULEID:;SRVR:TU4PR84MB0319; X-Forefront-PRVS: 09749A275C X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(377454003)(189002)(199003)(24454002)(101416001)(2950100001)(50466002)(65816999)(6116002)(2906002)(8676002)(5004730100002)(81166006)(8666005)(4326007)(5008740100001)(97736004)(33656002)(23756003)(68736007)(3846002)(4001350100001)(81156014)(77096005)(80316001)(47776003)(230700001)(117156001)(59896002)(106356001)(87266999)(54356999)(76176999)(50986999)(83506001)(105586002)(189998001)(86362001)(65806001)(42186005)(586003)(92566002)(65956001)(110136002)(64126003)(66066001)(36756003)(7059030);DIR:OUT;SFP:1102;SCL:1;SRVR:TU4PR84MB0319;H:[192.168.142.154];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;CAT:NONE;LANG:en;CAT:NONE; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;TU4PR84MB0319;23:Gpv1C5mnrGj4DvLdyvWcKjPegtKWc8DVAHAo7io?= =?iso-8859-1?Q?pX0djMiQ27vVhaKt7I8Gbu4r5/pYxCDLdl7dXWnuUreijuAkkJz4LzztvQ?= =?iso-8859-1?Q?l4A8wiCFZL9EITqqGOayxCZ1NW+75T+PAy6eV0dnExOghbmd5MxGiyUALP?= =?iso-8859-1?Q?pAwD2oJv772Sic6sBEe6EeoChbycCkPDc0cnp2QB6SQh9YGsmPPKpltCYc?= =?iso-8859-1?Q?J5rsUVyWdxfKGiPu5BdQGi3B6sPNNDH1P/Fyqr1uDPI4djidYWMp2YbCQA?= =?iso-8859-1?Q?mxjoaC+WA/aF4Vw0ff88TiyqtVKh/0i/N4pinHZLDvV0m0wAFev54pQTa1?= =?iso-8859-1?Q?IEF4b1M560FwbAI3xfAbbIcmuUIkruDczJYd6XASg3EKJjqXM0/0Ri4oLM?= =?iso-8859-1?Q?9xfKD8oL46t2LYdVz/oY0FmhWf+SIS8u5OhwTwWprsG5HRBhQSnrjPr+9j?= =?iso-8859-1?Q?AxRVEYX+Uktsw4pYmBv+Tfe0d10FteHPxRtgr40OwEIIkXM9reR3XzrSwW?= =?iso-8859-1?Q?8zR+6HO1nOgY7fOjUM7ZCuFUwsD+V/nS4H7YEoc79lizVyzgmiRZNSCcmb?= =?iso-8859-1?Q?vThEt+zVYrkXH5Br6c5nDh32xzJlkFXcl3sJGrC3Sr0PhVgUCyGUexjshT?= =?iso-8859-1?Q?yfPMXdqONIhZ1yruGnuVOxsahbuK90y+pCTj+z2g//h3RqVRQOSN6CaPld?= =?iso-8859-1?Q?J2ywy+VTBwM1TGsfq8NRy52vPoULEpVq6nILZrRdmwfGEex4GqRO0G7Ocs?= =?iso-8859-1?Q?hEEyxNZftrb2CQXn8LkPNbIPD6F0BzcwaBMOoXkTKrB8XcwoKV+S0Pg0nJ?= =?iso-8859-1?Q?bHspBdBoz7SbCIjTvoxRAh3UyG4ouhgm2oIPdqUuqCbeBldOyi+Jx+chXQ?= =?iso-8859-1?Q?M5c9hV70L61OONiqEL/gxSBdUDtxb7NYBvgZdVmkfjbh9loljpUfVktdiu?= =?iso-8859-1?Q?xgA+l+BEn56v/Qj0v6zsd159J6UEcYnGV9C+2o0+7K6jp1BSDGlp4k2xQA?= =?iso-8859-1?Q?wYHjAOAEtfsK9yw3dGQDCPnsYtDFXxDmkZAvXzOUiFSSG/9s6/WyFaz7bz?= =?iso-8859-1?Q?hCtTLyKFuK3E2bUHfTmHzHQL7SwYYNUG8u5C4CzVgKhhUWYXQFuGuRsZZS?= =?iso-8859-1?Q?MFRGuEEOuugmNU4PT78ass0+dosN1scoGlB2Tg6G4uIU9IMjttyJKVCvHj?= =?iso-8859-1?Q?Snpr8D6i0gXjjqsnbqa6bqKRdn+rzDJA0ynk9PCdKq4RMlj+hr1zjwhOPi?= =?iso-8859-1?Q?8eq0DaTFLAYH5D9BaUu450Lb1yiNkhkwOWwHb2F2gpGz3N0/28pocdJUB9?= =?iso-8859-1?Q?Wvvm2Z/FwVmvh2m+kVnYT7FHuXEmV8HSj4X9T5Nlo3X0g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;TU4PR84MB0319;6:19LbjGZdXmhNtqcLH2mQ5d0qarbztoBeaXk/sD2cvx/nf+JupIbtTZigjdVFPRjW7Un4bw4wmENuJOG3X4vkvhKHNs79pRiuCe0dlmycG9hfTJp2+ayym98r25MOvOtE/Z7QdCj+Um+F4NqXDczvUyb2l/lMnrlBoRa7QYb+nQBxdU/YWKzUnM73p2lhrOtpJdMQ2BEwpLPjzgm1nn4SX5hap5Ck3v7GqZBRig5Gkf6OuzepHnw70koKNttYHxZ2rX23guKUKMXBvYYQm+dOwIpPxaXMV2dCQwapTjPAYLg=;5:6Q5AU5CHm0zB6a2DXvrZLnq40eBIhTWiUtEzsIoK5X6VTykwH18QOlIf+A9ojY1C49vqTIfxF0XrU8vZAModY7g5Rje4OHa8I+ukbk26Aa+MYve9FABf45g7u9vLG7MBrF7K6KjqZDMtqUJ2IAyLCw==;24:9HM7nKP7AFK8+oLUWYPXm2C0zF8CuXi7TQvWwIplNPWWJNMlhK1X5h73axcvin2D8N1fNKvcXM2sj5GlGSZtFNOYPqkg+Q7+J+Vk8Kx/OFA=;7:4rdznMPRNzcD3QrlG1PxXsFkeHesxlwOnuxGTGnLrn//Y3V83uBnIQtAzIcYsToN34LLzN80KeoEfYqBpAh3paIowI+fEuHPcwyQtBHKigHx7CwASkJMEzHlGTx7bqwLFnlBzzgkzxB59bAjRceOQrYGk4RNZhszjJMyUyhdwYL8sKY2dMOupCQJ81zTUzBUklC09040iQcz/cZSCdyWZtX/7iZ7YGSY7nTZOBwhfto= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2016 19:17:54.8340 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR84MB0319 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/15/2016 01:22 PM, Peter Zijlstra wrote: > On Tue, Jun 14, 2016 at 06:48:05PM -0400, Waiman Long wrote: >> Currently, when down_read() fails, the active read locking isn't undone >> until the rwsem_down_read_failed() function grabs the wait_lock. If the >> wait_lock is contended, it may takes a while to get the lock. During >> that period, writer lock stealing will be disabled because of the >> active read lock. >> >> This patch will release the active read lock ASAP so that writer lock >> stealing can happen sooner. The only downside is when the reader is >> the first one in the wait queue as it has to issue another atomic >> operation to update the count. >> >> On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel, >> the fio test with multithreaded randrw and randwrite tests on the >> same file on a XFS partition on top of a NVDIMM with DAX were run, >> the aggregated bandwidths before and after the patch were as follows: >> >> Test BW before patch BW after patch % change >> ---- --------------- -------------- -------- >> randrw 1210 MB/s 1352 MB/s +12% >> randwrite 1622 MB/s 1710 MB/s +5.4% >> >> The write-only microbench also showed improvement because some read >> locking was done by the XFS code. > How does a reader only micro-bench react? I'm thinking the extra atomic > might hurt a bit. > A reader only benchmark will not go into the slow path at all. It is only when there is a mix of readers and writers will the reader slowpath be executed. I think there will be a little bit of performance impact for a workload that produce just the right amount of rwsem contentions. However, it is hard to produce a microbenchmark to create such a right amount of contention. As the amount of contention increases, I believe this patch will help performance instead of hurting it. Even then, the amount of performance degradation in that particular case will be pretty small. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Subject: Re: [RFC PATCH-tip v2 2/6] locking/rwsem: Stop active read lock ASAP Date: Wed, 15 Jun 2016 15:17:50 -0400 Message-ID: <5761A9DE.6040702@hpe.com> References: <1465944489-43440-1-git-send-email-Waiman.Long@hpe.com> <1465944489-43440-3-git-send-email-Waiman.Long@hpe.com> <20160615172242.GQ30921@twins.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160615172242.GQ30921@twins.programming.kicks-ass.net> Sender: linux-arch-owner@vger.kernel.org List-Archive: List-Post: To: Peter Zijlstra Cc: Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, Davidlohr Bueso , Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch List-ID: On 06/15/2016 01:22 PM, Peter Zijlstra wrote: > On Tue, Jun 14, 2016 at 06:48:05PM -0400, Waiman Long wrote: >> Currently, when down_read() fails, the active read locking isn't undone >> until the rwsem_down_read_failed() function grabs the wait_lock. If the >> wait_lock is contended, it may takes a while to get the lock. During >> that period, writer lock stealing will be disabled because of the >> active read lock. >> >> This patch will release the active read lock ASAP so that writer lock >> stealing can happen sooner. The only downside is when the reader is >> the first one in the wait queue as it has to issue another atomic >> operation to update the count. >> >> On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel, >> the fio test with multithreaded randrw and randwrite tests on the >> same file on a XFS partition on top of a NVDIMM with DAX were run, >> the aggregated bandwidths before and after the patch were as follows: >> >> Test BW before patch BW after patch % change >> ---- --------------- -------------- -------- >> randrw 1210 MB/s 1352 MB/s +12% >> randwrite 1622 MB/s 1710 MB/s +5.4% >> >> The write-only microbench also showed improvement because some read >> locking was done by the XFS code. > How does a reader only micro-bench react? I'm thinking the extra atomic > might hurt a bit. > A reader only benchmark will not go into the slow path at all. It is only when there is a mix of readers and writers will the reader slowpath be executed. I think there will be a little bit of performance impact for a workload that produce just the right amount of rwsem contentions. However, it is hard to produce a microbenchmark to create such a right amount of contention. As the amount of contention increases, I believe this patch will help performance instead of hurting it. Even then, the amount of performance degradation in that particular case will be pretty small. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Date: Wed, 15 Jun 2016 19:17:50 +0000 Subject: Re: [RFC PATCH-tip v2 2/6] locking/rwsem: Stop active read lock ASAP Message-Id: <5761A9DE.6040702@hpe.com> List-Id: References: <1465944489-43440-1-git-send-email-Waiman.Long@hpe.com> <1465944489-43440-3-git-send-email-Waiman.Long@hpe.com> <20160615172242.GQ30921@twins.programming.kicks-ass.net> In-Reply-To: <20160615172242.GQ30921@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Peter Zijlstra Cc: Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, Davidlohr Bueso , Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch On 06/15/2016 01:22 PM, Peter Zijlstra wrote: > On Tue, Jun 14, 2016 at 06:48:05PM -0400, Waiman Long wrote: >> Currently, when down_read() fails, the active read locking isn't undone >> until the rwsem_down_read_failed() function grabs the wait_lock. If the >> wait_lock is contended, it may takes a while to get the lock. During >> that period, writer lock stealing will be disabled because of the >> active read lock. >> >> This patch will release the active read lock ASAP so that writer lock >> stealing can happen sooner. The only downside is when the reader is >> the first one in the wait queue as it has to issue another atomic >> operation to update the count. >> >> On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel, >> the fio test with multithreaded randrw and randwrite tests on the >> same file on a XFS partition on top of a NVDIMM with DAX were run, >> the aggregated bandwidths before and after the patch were as follows: >> >> Test BW before patch BW after patch % change >> ---- --------------- -------------- -------- >> randrw 1210 MB/s 1352 MB/s +12% >> randwrite 1622 MB/s 1710 MB/s +5.4% >> >> The write-only microbench also showed improvement because some read >> locking was done by the XFS code. > How does a reader only micro-bench react? I'm thinking the extra atomic > might hurt a bit. > A reader only benchmark will not go into the slow path at all. It is only when there is a mix of readers and writers will the reader slowpath be executed. I think there will be a little bit of performance impact for a workload that produce just the right amount of rwsem contentions. However, it is hard to produce a microbenchmark to create such a right amount of contention. As the amount of contention increases, I believe this patch will help performance instead of hurting it. Even then, the amount of performance degradation in that particular case will be pretty small. Cheers, Longman