From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbcDTR6u (ORCPT ); Wed, 20 Apr 2016 13:58:50 -0400 Received: from mail-bn1bon0110.outbound.protection.outlook.com ([157.56.111.110]:44164 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751302AbcDTR6s (ORCPT ); Wed, 20 Apr 2016 13:58:48 -0400 Authentication-Results: linux.vnet.ibm.com; dkim=none (message not signed) header.d=none;linux.vnet.ibm.com; dmarc=none action=none header.from=hpe.com; Message-ID: <5717C34D.4000104@hpe.com> Date: Wed, 20 Apr 2016 13:58:37 -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: Pan Xinhui CC: Peter Zijlstra , Ingo Molnar , , Scott J Norton , Douglas Hatch Subject: Re: [PATCH v2] locking/pvqspinlock: Add lock holder CPU argument to pv_wait() References: <1460659318-53312-1-git-send-email-Waiman.Long@hpe.com> <20160420120805.GB3408@twins.programming.kicks-ass.net> <57178EED.1060207@linux.vnet.ibm.com> <20160420141949.GE3430@twins.programming.kicks-ass.net> <57179409.2010107@linux.vnet.ibm.com> In-Reply-To: <57179409.2010107@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [72.71.243.67] X-ClientProxiedBy: BY1PR15CA0026.namprd15.prod.outlook.com (10.162.17.164) To DF4PR84MB0314.NAMPRD84.PROD.OUTLOOK.COM (10.162.193.28) X-MS-Office365-Filtering-Correlation-Id: 48d5bd57-9771-4246-39f9-08d369456af7 X-Microsoft-Exchange-Diagnostics: 1;DF4PR84MB0314;2:mpp7I7oJtmrOBYCzOhGQCGO3QkUnShMdZ7S0dkTVekRxXycadiwYe8uSqCuUeFlGfSPRESuou3P8tkPvq7BpMOG2ZiDZwQmneQQ+lDua00dgoqlFkSqIBxXbB6WA7nz4RBsbrGXbUXLMyu2ZTRyVelXTDRSsxFhRUVT1Ux8vqDwGcrq4hMgwx8IpM467Lzsp;3:Q7jzQMqqsvXqE0b8v7U4MORzTi5HCeu7we4GQ2ls1RC4Je/yz1IXdYcm9khR1VukMtgsmda4dhdFJlsFF/zOy9Md+ycNXFr2YghEE/gLOXWujZaG+UHYGIGzVNH+lqTe;25:O3mPh5P3wlePcOU/+rdRaJnoFWapl7oB0tcORt1Q1/0HznPRTkIjAtLjjGfbO3+Zt1r5Dv1NduNlK5q1hDRhfZpjoagDS2uXnAqAVtww8UpUyhM7YbDbUp+v3kGOa92smQwG6Y4td0rxQUiiutsef9n3WkWon8GSbriDtyZAh+jlake/FavclctGrmnPljATERNBG4IaHu32wWKl3xPBLZDXSWze39GCWsHfxMhghjsODQzcHleoA1hYAMozuOuXETHhHGiG6vHaRHtBkETs0kLVeVMQ5VSINy90TX5UszAWD6y+XgjvNOZ6OJPs+vbjwuyQSDhK9ON9kz8GyyafkEo6z4GJWwnSmV9X5hiURfd7ZOHaLu9k11j3/Fv1ncS0uJ387MTyJb6KVtK8AmoKXOQUzCady5xyQQJHQqvNw9IeVZ27XYtR/9SajeD4hObvLbWVlShItxP6sHO4XJaPVoj0ausWoiAgAqjBugpxkDboeb3KNbXOSn2T35FF65s+1OsYl92wX5ogwQi1seDPp5WE7Ba2O2bCweHl48e0MSGmGzPS64255FE8DEQkKP2+NRR1Y9vIi1UutMP3w8MdrsMr1mIKpTkbWypW6gIOKPBweVaZyqs2oJqssjdmvOlq X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DF4PR84MB0314; X-LD-Processed: 105b2061-b669-4b31-92ac-24d304d195dc,ExtAddr X-Microsoft-Exchange-Diagnostics: 1;DF4PR84MB0314;20:X3juFWOojLe9fANKRG/cyh81KUAjAtNilSYD9gu+EnwM/4pENA0Q1Er35XhvaJ4lAJo/8b+9jYtr3yzGA80tDSbOd5kt5FTkFzlHR5q2POqefGiz2wDcgyqud9uxvtz73ogDUVzbTT6W7qGKI2ryPdzzP4jZC5tEj7QG9M/hctHWHuaSoM5HMKzL7EHpDfzgfvQJNW3uV+JVi/lWpNDLXzaZ9xKkmskjSDSl/HST+uD0IhH7IkC6aUfU3A2Xnh7EotodA3Y3lQeuEEUN4VmFV82yRwgQcSpc9z97hb/hv66fzUkky3KFKDg8o2tVsid4vLEFF87D2W0O8VlqEWQjJg==;4:fFusSQQLXgmFCTYfUkZQc9HDMNbmGvoUgBO2IttPvEJ+enM0aSQ4UpVsPLm3cEjg2iFEDvtr/yvOR0jsvOYxWL7D87OJSAA5XKWUS3VqI/ySWWtzZulqLSdpitrREC3TGmSn0s19k7x/sU+vrj2n9yyFO6C+rBDRMpFD7sWdPya5obundiGbeYpuUqeogL/qyhQRxUHt8dxk3elyd2AsVUIuFX1dGShANXEFSqQBKgIku0MtQPSXhyjLboTxvK2mpxL9S8SOfNiG4Cm03e1EaJ8g8EFerHh0fwdotwwVW9hhOYeqTk6IvvegCz20rPSP+7l08hMj16DkMGgg4LyrSs0u2x2KM0B0gKqfvQJu3t2F/hjST6xdiRXtep/RbdY0PEYgLtQRNJPw1YxYEf/3/nX2QynXFwvsjEMu6ZQyhi0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:DF4PR84MB0314;BCL:0;PCL:0;RULEID:;SRVR:DF4PR84MB0314; X-Forefront-PRVS: 0918748D70 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(42186005)(110136002)(83506001)(92566002)(3846002)(81166005)(2906002)(189998001)(93886004)(6116002)(86362001)(36756003)(1096002)(2870700001)(4001350100001)(5008740100001)(586003)(77096005)(66066001)(65956001)(65806001)(47776003)(33656002)(2950100001)(23676002)(117156001)(65816999)(50466002)(50986999)(76176999)(87266999)(54356999)(80316001)(4326007)(5004730100002);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0314;H:[192.168.142.160];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtERjRQUjg0TUIwMzE0OzIzOkRINFAvNVNNQ1laN3hrMWFtOC9UelFpc20x?= =?utf-8?B?aVNPZ1NaOTJ1a3lRNXdEamdxVWtMUllXY0w4NnFFMGpIc1FXdTdZNE8xMnAy?= =?utf-8?B?bFBBWnBQM3dTNms2cVQ4blNkT3RqN3MyVGFsMFpwTlY4YzBWekQ3YS9ENWVU?= =?utf-8?B?K1NDeXphTnZweitLS1Q0cjd1blptU0t3YUVSWEZYZCtRR2o3bkliNXlCVFk3?= =?utf-8?B?NkVtK0tNTEhIK2wzK1YzRzFPODNLZFRZK2tTaXJyWXhueUNidXRUaVNDeGkz?= =?utf-8?B?YWVFNmtUdW4vY1ZmcnZlMzZLSG5qTTJHOVJGQ0lSalJBYTlLV1hMaVY5MWRB?= =?utf-8?B?SXlmU0Rxc3RwWi9yZzZnRGxma1hVQnBoa3BZc1lIVWh5L0pvN3RqaS83Y2Np?= =?utf-8?B?eTdmb1pWV25DQUt2SUQ4UTVOTlVxeXVjYm95d3NONU9TQ09QOExxOHAreTNk?= =?utf-8?B?b0U5eHp3eDRRejV3d3VuTHJEMGhYMFU5clVZbTB4Q1p5K01KaHVLUTRSWUQ0?= =?utf-8?B?TDFxb2tUYWtadmgvckVWOFJ4ZHVUOFluK3JEYUYwQ1RwbGd0ZGo1R2UwZDVE?= =?utf-8?B?RE9DY1M1dFpYd0FLZmUzYXk4QS9MYllOSmxQNTl4SXl4R0d3WEpVaWRZMWZI?= =?utf-8?B?VVNGS2twSDZadDJWOE9ETUhuK05idGtjSmhtM1JYaUNwSlUvOFhyTmFzK291?= =?utf-8?B?bldkNnJ3ZTdueUp5TEtYM0xHcjljUXljaTFZejdSZHZSZ0JHNitKLzUzcmVu?= =?utf-8?B?Ukh6MGZzUVdSQTlnUlNpVFVyL2x0RkI5bVhqQk0vbXZLclhzVnZBdVFwYys3?= =?utf-8?B?WTA4LzB2RlIzOXljazNGQ3FDSkNLdWZyejZSMVVqZGNKTHFhNEthNDZBamxK?= =?utf-8?B?Q0pIcjFyRG1wNUVNVFB1eG01M0ZXbG1IY1ZoT0YrZXdLMURoMWRPcFdNRVFP?= =?utf-8?B?bi96a2gySkw4dHZZYzNuby9VNjdDU2JjVlJPMVpvVzR6V0IvVVZaUzhlUVhU?= =?utf-8?B?QVpYeWZzc0JaNkQ0WlU4UDB1ZHBxWWt1S1R5TEdaeFpKaEJET2xuL2RqdnFL?= =?utf-8?B?TGZVQi95VDIwY2hMRkI3dkZPWTRwSE1PNlZZVG1KdmNPSkRCdEJ3UnlYbjVE?= =?utf-8?B?aTRMcUdXeXU5bzZzemlUdG1tc211SFVEeVAzRTVIZjJOODk5Zng3Ykd6dk9l?= =?utf-8?B?dU1RNnhjUG16ckprb1lNdkRVaCswcWFDQkdFQkhqSk95UXpXTDlwOU9vK2xq?= =?utf-8?B?SW1HWlljTmhmVVBqWU1JMHNkRXJvdGdxZitzK2pIQW96YmdIRW1OZUdNZUFn?= =?utf-8?B?WWNTc0NIVWdEVXVocnR4MngrUk44dllHNnkvSU1VOTZqMS8vSjF3ekpkeVZJ?= =?utf-8?B?Tm1VdTFZUDZWcXRCbHZUZFhXUWNDRDE3QUFsQXNJZTRYVjBzL0VvSzV5eHdj?= =?utf-8?Q?wIBqFQ=3D?= X-Microsoft-Exchange-Diagnostics: 1;DF4PR84MB0314;5:WkuYCUWyRWo9BeLkOPxY7PS3Z36+Fc4XKUrRQd/UkPZ0EQrujZN4yaWIlryc/FuicP0k+Rke2pRsC7Z6fZp5F3y6ZsF2k5ZHT8JIoTL6sxRwec5dT1zC3XvXV3CXJ/47wdlV0VHpk5dl1kZIIMDfzBaFa/Is0Wu+htyKNJTmdDkWbvCNAWgKVErIIkqrg+V3;24:nkWClwOItYHKxfJkVYaXr0LzmP0Sk4hvjysV2JGZIgzKkYRr7/sOq556M2RHQer3NKZE7VDfvQhmc86XhvaDTpH+6tx2b+PrOej5eHzcR98=;7:noJP2pP4EEU9bSxRPYlEaWnLJhSctPGRRalEfJJ/W4KMde0UeZtSaa7z1RV3rXCTHUxqCwLEkKjudyXGlail7a4YRRiFOlcWGT3kEJ6Dzu19foCFVO07uz453CkCJWKOT9Rcd52XBgnOxSMGrYYIJ691JK8oSEPSQ181aY+2+Q/Bgk/pBZaj2jK45zOYcL5O4zoTzjwiLU5NT0eAJX1GsENMJXfcvdzJwatcovIYkTo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2016 17:58:44.6524 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0314 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/20/2016 10:36 AM, Pan Xinhui wrote: > > On 2016年04月20日 22:19, Peter Zijlstra wrote: >> On Wed, Apr 20, 2016 at 10:15:09PM +0800, Pan Xinhui wrote: >>> So there is such case that we search the whole hashtable and the lock is not found. :( >>> Waiman assume that if l = null, the lock is not stored. however the lock might be there actually. >>> But to avoid the worst case I just mentioned above, it can quickly finish the lookup. >> >>>>> + >>>>> + /* >>>>> + * We try to locate the queue head pv_node by looking >>>>> + * up the hash table. If it is not found, use the >>>>> + * CPU in the previous node instead. >>>>> + */ >>>>> + hn = pv_lookup_hash(lock); >>>>> + if (!hn) >>>>> + hn = pn; >>>> This is potentially expensive... it does not explain why this lookup can >>>> fail etc.. nor mentioned that lock stealing caveat. >>>> >>> Yes, it's expensive. Normally, PPC phyp don't always need the correct >>> holder. That means current vcpu can just give up its slice. There is >>> one lpar hvcall H_CONFER. I paste some spec below. >> Ok, so if we can indeed scan the _entire_ hashtable, then we really >> should not have that in common code. That's seriously expensive. >> > Okay, I will try to add the holder lookup code in arch/... > > But I just come up with one idea, > in __pv_queued_spin_unlock_slowpath() > we will kick the node->cpu, who will become the holder soon. > I think we can somehow record the node->cpu and use it in pv_wait_node :) > > thanks > xinhui > That will make the code more complex. Unless you find it provide real performance improvement, I won't suggest doing that for the time being. Cheers, Longman