From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751738AbcF0KUO (ORCPT ); Mon, 27 Jun 2016 06:20:14 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:29241 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750736AbcF0KUM (ORCPT ); Mon, 27 Jun 2016 06:20:12 -0400 X-IBM-Helo: d23dlp02.au.ibm.com X-IBM-MailFrom: xinhui.pan@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 27 Jun 2016 18:19:42 +0800 From: xinhui User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Peter Zijlstra , panxinhui CC: Boqun Feng , linux-kernel@vger.kernel.org, mingo@redhat.com, dave@stgolabs.net, will.deacon@arm.com, Waiman.Long@hpe.com, benh@kernel.crashing.org Subject: Re: [PATCH] locking/osq: Drop the overload of osq lock References: <1466876523-33437-1-git-send-email-xinhui.pan@linux.vnet.ibm.com> <20160625142447.GK30154@twins.programming.kicks-ass.net> <20160625152130.GA2452@insomnia> <20160625160922.GL30154@twins.programming.kicks-ass.net> <20160625161307.GZ30927@twins.programming.kicks-ass.net> <90D0C23D-65D5-40A8-89F1-4D02506A9CBC@linux.vnet.ibm.com> <20160625191217.GO30154@twins.programming.kicks-ass.net> <20160627075522.GT30154@twins.programming.kicks-ass.net> In-Reply-To: <20160627075522.GT30154@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062710-0044-0000-0000-000001BA63AD X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062710-0045-0000-0000-000005034F0A Message-Id: <5770FDBE.6000800@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-27_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606270116 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016年06月27日 15:55, Peter Zijlstra wrote: > On Sun, Jun 26, 2016 at 12:59:01PM +0800, panxinhui wrote: >> >>> 在 2016年6月26日，03:12，Peter Zijlstra 写道： >>> >>> On Sun, Jun 26, 2016 at 01:27:51AM +0800, panxinhui wrote: >>> >>>> by the way I still think mutex_unlock has a big overload too. >>> >>> Do you mean overhead? >>> >> oh, maybe you are right. > >> mutex_unlock ’s implementation uses inc_return variant on ppc, and >> that’s expensive. I am thinking of using cmpxchg instead. > > That statement doesn't make any sense. PPC is an LL/SC arch, inc_return > and cmpxchg are the 'same' LL/SC loop. > This is a little optimize. if there are lock waiters, the lockval is minus X, when we call unlock, it will inc the lockval, if it is <= 0, enter unlockslowpath to wakeup the waiters, and set lockval to 1 in the slowpath. SO there is no need to inc lockval if it is already a minus number. therefore we can save one store or loads/stores in LL/SC loops the base idea is from code below, if (!atomic_read(&lk)//no need to call atomic_inc_return which is expensive. atomic_inc_return(&lk))