From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751309AbcFQO22 (ORCPT ); Fri, 17 Jun 2016 10:28:28 -0400 Received: from mail-by2on0131.outbound.protection.outlook.com ([207.46.100.131]:26344 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754450AbcFQO2V (ORCPT ); Fri, 17 Jun 2016 10:28:21 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=waiman.long@hpe.com; Message-ID: <576408F7.8020901@hpe.com> Date: Fri, 17 Jun 2016 10:28:07 -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: Davidlohr Bueso CC: Peter Zijlstra , Ingo Molnar , , , , , , , Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch Subject: Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier References: <1465944489-43440-1-git-send-email-Waiman.Long@hpe.com> <1465944489-43440-2-git-send-email-Waiman.Long@hpe.com> <20160615165659.GC2094@linux-80c1.suse> <20160615171250.GO30921@twins.programming.kicks-ass.net> <20160615182724.GD2094@linux-80c1.suse> <20160615184007.GW30921@twins.programming.kicks-ass.net> <20160617011155.GA14591@linux-80c1.suse> In-Reply-To: <20160617011155.GA14591@linux-80c1.suse> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [71.168.64.123] X-ClientProxiedBy: SN1PR01CA0011.prod.exchangelabs.com (10.165.224.21) To AT5PR84MB0306.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.28) X-MS-Office365-Filtering-Correlation-Id: cd5e2814-74a0-4a4b-83b9-08d396bba027 X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;2:of55iFT7WZPxPrBIkqyeis8eHNG+BzwyBEVaEP5GOJIowgKGANHR8LTO9gFn3WQr9N3z4VGJC48Ma9x4GBc8dN70PxtmHwK4lE6DAgpzvL4XlVgbjHvBL5g+XE7QvE8RbyOY5qBuzuk9BJ/pHepK/WoDPLUBT/J192NCkyMjHwMY7Ohp1fGmhx7kG7GkSiw/;3:uDQSHjTwVOYzTFy9xeZW6xCOnw87gd961kcROyFTPEVNxiDWLaJguCng3dZWr8pa2b0enSu4UX3nVs5m098xZM4IapmhDYxaByFtdDDO/Sk32UMXfCirNJO5mbTnQuyK X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0306; X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;25:UB6Gy1rTgn8SKdE7YlYZI1gjrpppIz7PXlSZ2l8AmndReDax/oxrqsY+SWC7SK+lwuW78R3Jv/0HhdG0Q4XVv/keFcAsFGMtX09xNWxMoioJHeT/ANN98OyDcR1oXhZ5pv5XwW6GmYTwv8sjBbFMVq0KX8mrXnxR+akh1zqaD+rbgS8j4raNQACmIxm/eYH2wfE8uQ2i7bu7O9R2qx9j/6BuyPBKdMeWcn8e6Q+JdiuGdjuXXcIhp9ue1eTR9sNIjjNi7YFccLH2oy966DecWAlS/nF58vYC9u6aZbvMFcHeqGNcLtPiSRDkncMl1hQu/CTQVCQI+T8BVZ0I/n7buZPzxBmUh1ksDWJ9TDIrVZ34SjMSWcVnnNa7RjssDaN0Jn6LqezmkC1s7kQAlIaN08FIywENXW5RC+CHSCJdc0b4xcfUOAiQ2FhPZyIaOobJKE7t5s7HQvIuS4D2MdRrO+bvRFrIudNdLFFVlm1dvGBhkkMkobJBh38FXiCXpsei2d21QmWPTSh/ERiR6dDMw6HYmsI77/wuVOzX5Vx2HuwsyiLDb5Qi4WBDpxq5b8PTpRRBU6sqTcvVmZAANJykb9SlQgJT6wi8O/7+E/9DSanS6OcfHhlIotQPX076Acckk6k7NqC6b+cTyXfPBKSlO1pccCvGuYB2WU3TvIbazxCbBgbaGtoaXCmhJ1G7WCcfqzTZjTeFmtWaiyWcohdAiA== X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;20:y6QBYHMlo15RgP9yxckElQeebrnrDxn0aXIeVWfbIVH/UUykQ4pRQ1+SaXezn7k0m1L2A4XRF2Wu6lPyJl17o5EQ1fvopNecOjSCOKFJqnC7ji8drHfSjosB0YLoDrViCEUU5BDAC/BqgOf+BBxEjP0ylnMnu+RoYKOP1Q0Rfq1ApnY60uyumhv6EvPHmsg5kzDP5gLVZlqe7umxSoZxR6Hx5UxY/nA2If7R/OmZPwRVh1ZsZRfJdh378BgIeUp+ktCsrWWfJvn/8PiU/lxoFGYLQQHZyx2vpaWcfvaBHH8uq8q1I2Gg8HHCdHtT4mAeZeZEZjZSZvQ1i6D62HFzrmn/u0sldByKRGM+RHuS+W9kLOaCjf0FkkPM25ot7t6PL9gkwiTAQmz9Bq8Ih4F0UqyAiUapfKWxEUQ1q71AvPQkiMLTmlOh+4HMbAAEVIqm8ra7eiqREEgNuA1a5a7w4gnkrTityPgUIXQzJJSABHH0/+40T0zps9PapU9IUs2t;4:PsiiDTC/p6BkytuHrdj/9GYst5hys3NpHeLINumzyk+xmWt5HDFoxnDu3Wd3PWrUIFYK+eZoE7KT+gO8JQJVb/0bYA/HUC1SSG38nOEPCIIP2/dluE5T8jj0Y+WG5NDxQgPw0835KmJeS8YbLDB992+YAs1qci/uDU/EkaAbpsM2Py7LwLyYNbsqXR0Cqof2qGf0AU++rrnuVk4QJ9/SqjampLJQfvEtIuDXaSGVUyTpWiYYBrOnThm7FYqUd5kzHMctPAifi5ZoZqq8U8QEtbD/hPMIHdeiBSEuZRMmyhITkQ1vD+++w24IA6KW8oefJJnI850wRJ3Inj4pzpcCZqO5d18AQIX9HYAVQmdMefRSjFU5j9hgAgWZvJvsBiba X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:AT5PR84MB0306;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0306; X-Forefront-PRVS: 09760A0505 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(199003)(24454002)(52314003)(377454003)(189002)(33656002)(86362001)(64126003)(5004730100002)(65956001)(36756003)(59896002)(66066001)(23756003)(6116002)(5008740100001)(3846002)(42186005)(586003)(65806001)(93886004)(83506001)(68736007)(92566002)(189998001)(230700001)(4001350100001)(110136002)(97736004)(105586002)(87266999)(54356999)(99136001)(76176999)(65816999)(50986999)(8666005)(117156001)(106356001)(47776003)(2950100001)(2906002)(50466002)(101416001)(4326007)(8676002)(77096005)(80316001)(81166006)(81156014)(7059030);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0306;H:[192.168.142.156];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;AT5PR84MB0306;23:XmFXxp10T9yEzNuxTRgnM+RGfhXg1GdEPBXcVH+?= =?iso-8859-1?Q?gE4gBh9vZpO3iFHjQN/uhYeuevQhKWmUHHmfjZ1EZ5qBHGpVSgSndQg4WW?= =?iso-8859-1?Q?fUhXduVrCGIS+4kysQM8wZsgU1S+8RZw6TjsPJuBg9BmJyPnTtMNUqBokM?= =?iso-8859-1?Q?qmPTQ0wvfxIerUW+KzXhfA6928LtIWnFUlY8CjK4XCGZzW2Q/wMAQGposJ?= =?iso-8859-1?Q?QO50qP8zIRSE80o/RXRaOYV4TZZxbxLpZ5mWxr6FI2usZROv8J9I+1KFyZ?= =?iso-8859-1?Q?aFCaMGj1vrv4PghjK8WyabQlmfsaPKFJqnCY3UFlf5eoMYTATBsPsRH/4i?= =?iso-8859-1?Q?3RKFivHhq0mVOusZHcbEcqUnCGRrMYXX8E4sLpLdTJtLhlManx0OcAXalV?= =?iso-8859-1?Q?P/DEMcm84khDUoToYJPDm+SMYJDg7rSILkHzJdFgOLyD142qTllg0SKKVE?= =?iso-8859-1?Q?3jUhqHiVxgfdIB2ZL+C8ew/JuIAtQ6OmKQ9vkn2KWGMhjziNSJMQknn98T?= =?iso-8859-1?Q?vjBDlHIwbMmRZDebIVATkWuTdRJMy8ImV1FQ4bsRyUec1HSGdHnUtZwV7d?= =?iso-8859-1?Q?VRD9hTvcBp3hiSqEE8e77QcKjswdGCiRGiGSMLI73Tf/aUAJXM4mC7iCgQ?= =?iso-8859-1?Q?ddtwjk3JwEifxfrjLDh390sJduH+UErfB0npM8lDR5aFFm6WXkIl3EiUkj?= =?iso-8859-1?Q?pWgy6IWk6hNRwLauOb3yTxgc9Z1ahxu3cQz3ioNkhqGQRRHjIq0nRtb9mM?= =?iso-8859-1?Q?RBzyupJEjTttgqEPsKJuVBWGAcuIBeOa+4Zh3s9bOXvkleEJFY9e2S+5RN?= =?iso-8859-1?Q?1WKG6d8cIwE2j1TlbKl0wH4lL+0phtlgUK+IVlanfEiiV54trS5DwlrFh4?= =?iso-8859-1?Q?fDLVVVP6DJih0BrskgZtPVUYDnz4SHFXqXQ2Mn+vDBqTVbqhzkK4so2KS7?= =?iso-8859-1?Q?Dz4e2XcKHXOZ9j1awrpg1tXIExQyHcG4SHrClphK1CcrmkngCD+8L7gCfh?= =?iso-8859-1?Q?kiORMGlANtz+f/FszZBWCBfsbybDbTgY3Q1Fhcp+6zYvSoZ5um3nlQZeoh?= =?iso-8859-1?Q?0Y1nkl1aFRni/j6Zp9yQcF8wYXLtcb0X9SVBFVhGP7Ilwm8YUO4r4An9CA?= =?iso-8859-1?Q?L41RYLvR9zAyQHEInSgzv5syf8beWZMSOnFsxuA+zQuD06c+xMor3VzWuC?= =?iso-8859-1?Q?TNmXq7R/lisdTVEWmrG1iOXaWbR0ev2KF60J/D0Alzy5wGiUVptxxwpFTE?= =?iso-8859-1?Q?tKCkc6Z9JOnJnEUv/Dbt8mwpcjBfUjuih4be74dKEfxrdXd+VkGhNygb+c?= =?iso-8859-1?Q?JUJpXE8AZuaHAEQaDUUXXiv/LVZ1cjCvBVuK5cneiW6hzeBfUDt2pgzfZG?= =?iso-8859-1?Q?edhRQfl7c0dJ3ODY+aR8NncFCAa7nZzt/IukPzoXy71wSNNLboQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;AT5PR84MB0306;6:djBxIIo79owLQCh3wBy5oE+JZYV5lcXMyrQIN93MC2yiyCl4DU9zyZTWMKmYKZk5s5WNhKX49yitM8mf6U9pyKF2Dh1aLPvCPbRw4eLvq3nO55gEtGzna+MLz1aSVGDskgIbd9LQK35kWdRj/D95BY2S5EI3zE0wEpk0tT6MWtwlggmQQgTi+RUNgFD7THVBBrFhzmupCcUCQ6G1zFbCAwndTRWLUcC5JBmQSLv7ATq1fgYy+7EZ16PaBUHpkhx3K9APnH/fTiZewp+2atRlhfJHKNXBx/AddPF7SuDgfBc=;5:HA2haesF0W4JgRidj8UZvqUF1pTnMe6Jx/NnukWHOdoBBDF+guxozrcritk1epey3Wb+6O49LN6jJHPfkkqXdUnWuweqzyt8MDj/tloy4BnmA0CHBR2hH7q/fndcBnRLuMgdmkr9o1sgpaAA0MUJKw==;24:nf9XA1z0ZqmLMLQHOwPnNA7e+3zVg+nXsiVvyuTbyVhg/3BJlpzdZUTkVLrDux62jE1LaSg5wcHVhEyXCdQKv4uNrIf1WExNuNAMXMeDfXw=;7:FoI1BSWKwRH5b3H04eyQM2ZZ6QFINQiHQPswnrHhG5aeUm92CvO4BcVU4O5J8EltdJCMAXTrQeVScXZquaDdzg/uY2ZQe1IGg+XTSeVdavdLDGavpjCfKXm+XEKfu1WtjgEL63chAqpdZLKU78HvB/eWilfcdWY/MIGCXTm311qA0YP988vUn8cV/zZ80VR4RZ1GcHKymLvI6DN6TLQpKKgEP6Gq1P7i6a6QDVHx3KD/61CYxAzhmsD/0P7HHKtg SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2016 14:28:16.6426 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0306 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/16/2016 09:11 PM, Davidlohr Bueso wrote: > On Wed, 15 Jun 2016, Peter Zijlstra wrote: > >> Yeah, see a few patches further in this series, where he guards a >> variables with the osq_lock. > > So one problem I have with all this is that if we are hardening > osq_lock/unlock() > because of some future use that is specific to rwsems, then we will > immediately > be hurting mutexes for no good reason. > I am going to change it to use smp_acquire__after_ctrl_dep() as suggested by PeterZ. Is that a good enough compromise? I have also changed the xchg in the unlock side to xchg_release which could help performance in some archs. The thing is when developers see the name osq_lock/osq_unlock, they will naturally assume the proper barrriers are provided which is not currently the case. Anyway, the change won't affect x86, it is probably ARM or PPC that may have an impact. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Subject: Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier Date: Fri, 17 Jun 2016 10:28:07 -0400 Message-ID: <576408F7.8020901@hpe.com> References: <1465944489-43440-1-git-send-email-Waiman.Long@hpe.com> <1465944489-43440-2-git-send-email-Waiman.Long@hpe.com> <20160615165659.GC2094@linux-80c1.suse> <20160615171250.GO30921@twins.programming.kicks-ass.net> <20160615182724.GD2094@linux-80c1.suse> <20160615184007.GW30921@twins.programming.kicks-ass.net> <20160617011155.GA14591@linux-80c1.suse> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160617011155.GA14591@linux-80c1.suse> Sender: linux-alpha-owner@vger.kernel.org List-Archive: List-Post: To: Davidlohr Bueso Cc: Peter Zijlstra , 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, Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch List-ID: On 06/16/2016 09:11 PM, Davidlohr Bueso wrote: > On Wed, 15 Jun 2016, Peter Zijlstra wrote: > >> Yeah, see a few patches further in this series, where he guards a >> variables with the osq_lock. > > So one problem I have with all this is that if we are hardening > osq_lock/unlock() > because of some future use that is specific to rwsems, then we will > immediately > be hurting mutexes for no good reason. > I am going to change it to use smp_acquire__after_ctrl_dep() as suggested by PeterZ. Is that a good enough compromise? I have also changed the xchg in the unlock side to xchg_release which could help performance in some archs. The thing is when developers see the name osq_lock/osq_unlock, they will naturally assume the proper barrriers are provided which is not currently the case. Anyway, the change won't affect x86, it is probably ARM or PPC that may have an impact. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Date: Fri, 17 Jun 2016 14:28:07 +0000 Subject: Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier Message-Id: <576408F7.8020901@hpe.com> List-Id: References: <1465944489-43440-1-git-send-email-Waiman.Long@hpe.com> <1465944489-43440-2-git-send-email-Waiman.Long@hpe.com> <20160615165659.GC2094@linux-80c1.suse> <20160615171250.GO30921@twins.programming.kicks-ass.net> <20160615182724.GD2094@linux-80c1.suse> <20160615184007.GW30921@twins.programming.kicks-ass.net> <20160617011155.GA14591@linux-80c1.suse> In-Reply-To: <20160617011155.GA14591@linux-80c1.suse> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Davidlohr Bueso Cc: Peter Zijlstra , 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, Jason Low , Dave Chinner , Scott J Norton , Douglas Hatch On 06/16/2016 09:11 PM, Davidlohr Bueso wrote: > On Wed, 15 Jun 2016, Peter Zijlstra wrote: > >> Yeah, see a few patches further in this series, where he guards a >> variables with the osq_lock. > > So one problem I have with all this is that if we are hardening > osq_lock/unlock() > because of some future use that is specific to rwsems, then we will > immediately > be hurting mutexes for no good reason. > I am going to change it to use smp_acquire__after_ctrl_dep() as suggested by PeterZ. Is that a good enough compromise? I have also changed the xchg in the unlock side to xchg_release which could help performance in some archs. The thing is when developers see the name osq_lock/osq_unlock, they will naturally assume the proper barrriers are provided which is not currently the case. Anyway, the change won't affect x86, it is probably ARM or PPC that may have an impact. Cheers, Longman