From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751691AbcFYR3Q (ORCPT ); Sat, 25 Jun 2016 13:29:16 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:15171 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751123AbcFYR3N convert rfc822-to-8bit (ORCPT ); Sat, 25 Jun 2016 13:29:13 -0400 X-IBM-Helo: d28dlp03.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: <20160625164527.GD2384@insomnia> Date: Sun, 26 Jun 2016 01:27:56 +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: <1466876523-33437-1-git-send-email-xinhui.pan@linux.vnet.ibm.com> <20160625142447.GK30154@twins.programming.kicks-ass.net> <20160625152130.GA2452@insomnia> <20160625161540.GM30154@twins.programming.kicks-ass.net> <20160625164527.GD2384@insomnia> To: Boqun Feng X-Mailer: Apple Mail (2.3124) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062517-0008-0000-0000-000002CB4E53 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062517-0009-0000-0000-00000DC4BCB4 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-25_08:,, 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-1606250207 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 在 2016年6月26日，00:45，Boqun Feng 写道： > > On Sat, Jun 25, 2016 at 06:15:40PM +0200, Peter Zijlstra wrote: >> On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: >>> So on PPC, we have lppaca::yield_count to detect when an vcpu is >>> preempted, if the yield_count is even, the vcpu is running, otherwise it >>> is preempted(__spin_yield() is a user of this). >>> >>> Therefore it makes more sense we >>> >>> if (need_resched() || vcpu_is_preempted(old)) >>> >>> here, and implement vcpu_is_preempted() on PPC as >>> >>> bool vcpu_is_preempted(int cpu) >>> { >>> return !!(be32_to_cpu(lppaca_of(cpu).yield_count) & 1) >>> } >>> >>> Thoughts? >> >> Would that not have issues where the owner cpu is kept running but the >> spinner (ie. _this_ vcpu) gets preempted? I would think that in that >> case we too want to stop spinning. >> > do you mean that the spinner detect itself had yield out during the big spin loop? It is very possible to happen. BUT if spinner(on this vcpu) yield out, the next spinner would break the spin loop. AND if spinner detect itself yield out once, it’s very possible to get the osq lock soon as long as the ower vcpu is running. SO I think we need just check the owner vcpu’s yield_count. > I don't think we want(or need) to stop the spinning of _this_ vcpu in > that case? Because it has already been preempted, when it gets back to > run, the owner may still be running and haven't set ->locked to 1 yet, > which means spinning on this vcpu is still worthwhile. > > I think the proper logic here is that in the optimistic spin queue, if > any one found its predecessor's vcpu was preempted, it should stop > spinning, because it's very likely that it would not see ->locked > becoming 1 in a short time. > agree!!! this vcpu need yield out too if the owner’s vcpu has yield out. >> Although, if all vcpus are scheduled equal, it might not matter on >> average.