From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751787AbcFCHDg (ORCPT ); Fri, 3 Jun 2016 03:03:36 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:27089 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751308AbcFCHDf (ORCPT ); Fri, 3 Jun 2016 03:03:35 -0400 X-IBM-Helo: d23dlp03.au.ibm.com X-IBM-MailFrom: xinhui.pan@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Fri, 03 Jun 2016 15:02:11 +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: Benjamin Herrenschmidt , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, virtualization@lists.linux-foundation.org CC: paulus@samba.org, mpe@ellerman.id.au, peterz@infradead.org, mingo@redhat.com, paulmck@linux.vnet.ibm.com, waiman.long@hpe.com Subject: Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock References: <1464859370-5162-1-git-send-email-xinhui.pan@linux.vnet.ibm.com> <1464859370-5162-3-git-send-email-xinhui.pan@linux.vnet.ibm.com> <1464917520.26773.11.camel@kernel.crashing.org> <1464917548.26773.12.camel@au1.ibm.com> <57510353.1020209@linux.vnet.ibm.com> <1464928427.26773.26.camel@kernel.crashing.org> In-Reply-To: <1464928427.26773.26.camel@kernel.crashing.org> 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: 16060307-0040-0000-0000-000001ADC74E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16060307-0041-0000-0000-000009CCFF7D Message-Id: <57512B73.5010005@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-03_04:,, 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-1606030078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016年06月03日 12:33, Benjamin Herrenschmidt wrote: > On Fri, 2016-06-03 at 12:10 +0800, xinhui wrote: >> On 2016年06月03日 09:32, Benjamin Herrenschmidt wrote: >>> On Fri, 2016-06-03 at 11:32 +1000, Benjamin Herrenschmidt wrote: >>>> On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote: >>>>> >>>>> Base code to enable qspinlock on powerpc. this patch add some >>>>> #ifdef >>>>> here and there. Although there is no paravirt related code, we >> can >>>>> successfully build a qspinlock kernel after apply this patch. >>>> This is missing the IO_SYNC stuff ... It means we'll fail to do a >>>> full >>>> sync to order vs MMIOs. >>>> >>>> You need to add that back in the unlock path. >>> >>> Well, and in the lock path as well... >>> >> Oh, yes. I missed IO_SYNC stuff. >> >> thank you, Ben :) > > Ok couple of other things that would be nice from my perspective (and > Michael's) if you can produce them: > > - Some benchmarks of the qspinlock alone, without the PV stuff, > so we understand how much of the overhead is inherent to the > qspinlock and how much is introduced by the PV bits. > > - For the above, can you show (or describe) where the qspinlock > improves things compared to our current locks. While there's > theory and to some extent practice on x86, it would be nice to > validate the effects on POWER. > > - Comparative benchmark with the PV stuff in on a bare metal system > to understand the overhead there. > > - Comparative benchmark with the PV stuff under pHyp and KVM > Will do such benchmark tests in next days. thanks for your kind suggestions. :) > Spinlocks are fiddly and a critical piece of infrastructure, it's > important we fully understand the performance implications before we > decide to switch to a new model. > yes, We really need understand how {pv}qspinlock works in more complex cases. thanks xinhui > Cheers, > Ben. >