From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752473AbcFZPLn (ORCPT ); Sun, 26 Jun 2016 11:11:43 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44266 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054AbcFZPLm convert rfc822-to-8bit (ORCPT ); Sun, 26 Jun 2016 11:11:42 -0400 X-IBM-Helo: d28dlp02.in.ibm.com X-IBM-MailFrom: xinhui@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH] locking/osq: Drop the overload of osq lock From: panxinhui In-Reply-To: <20160626142922.GD6512@insomnia> Date: Sun, 26 Jun 2016 23:11:22 +0800 Cc: panxinhui , Peter Zijlstra , Pan Xinhui , linux-kernel@vger.kernel.org, mingo@redhat.com, dave@stgolabs.net, will.deacon@arm.com, Waiman.Long@hpe.com, benh@kernel.crashing.org Content-Transfer-Encoding: 8BIT References: <20160625142447.GK30154@twins.programming.kicks-ass.net> <20160625152130.GA2452@insomnia> <20160625161540.GM30154@twins.programming.kicks-ass.net> <20160625164527.GD2384@insomnia> <20160625192025.GP30154@twins.programming.kicks-ass.net> <20160626061057.GA6512@insomnia> <20160626065926.GB6512@insomnia> <20160626142922.GD6512@insomnia> To: Boqun Feng X-Mailer: Apple Mail (2.3124) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062615-0004-0000-0000-000002B00A38 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062615-0005-0000-0000-00000DA8C531 Message-Id: <7558F9A4-6702-42BA-9287-A8A574F16879@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-26_07:,, 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-1606260169 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 在 2016年6月26日，22:29，Boqun Feng 写道： > > On Sun, Jun 26, 2016 at 03:08:20PM +0800, panxinhui wrote: > [snip] >>> @@ -106,6 +109,9 @@ bool osq_lock(struct optimistic_spin_queue *lock) >>> node->prev = prev; >>> WRITE_ONCE(prev->next, node); >>> >>> + old = old - 1; >>> + vpc = vcpu_preempt_count(); >>> + >>> /* >>> * Normally @prev is untouchable after the above store; because at that >>> * moment unlock can proceed and wipe the node element from stack. >>> @@ -118,8 +124,14 @@ bool osq_lock(struct optimistic_spin_queue *lock) >>> while (!READ_ONCE(node->locked)) { >>> /* >>> * If we need to reschedule bail... so we can block. >>> + * An over-committed guest with more vCPUs than pCPUs >>> + * might fall in this loop and cause a huge overload. >>> + * This is because vCPU A(prev) hold the osq lock and yield out, >>> + * vCPU B(node) wait ->locked to be set, IOW, wait till >>> + * vCPU A run and unlock the osq lock. >>> + * NOTE that vCPU A and vCPU B might run on same physical cpu. >>> */ >>> - if (need_resched()) >>> + if (need_resched() || vcpu_is_preempted(old) || vcpu_has_preempted(vpc)) >>> goto unqueue; >>> >> >> the prev might change, so we need read node->prev every loop, then check vcpu preempted. >> > > Right you are on the possibility of the prev's change, however, even if > we reread node->prev, the prev is still not stable after we read, that > is the prev can change after we read in the loop and before we check the but the next loops we will detect the owner is preempted, right? > vcpu preemption in the next loop, therefore whether the reread is well,think the case below. 3 vcpu try to get the osq lock. IF you don’t re-read the prev. A B C preempted detect A preempted, then break loops and do unqueue spin loops, because B (the prev ) is running, preempted detect B preempted then break loops and do queue.// looks like it’ too late to break the loops running SO we can get the rules, IF the queue nodes looks like vcpu A,B,C,D,E,F,G,….. more spinners say, if vcpu B,F is preempted, then, we could know vcpu C,D,E should stop the spinning. right? and all other vcpu after F, say G,H,…should stop spinning too. thanks xinhui > Regards, > Boqun > >>> cpu_relax_lowlatency(); >>