From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755951AbcJUPJG (ORCPT ); Fri, 21 Oct 2016 11:09:06 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54363 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933459AbcJUPJC (ORCPT ); Fri, 21 Oct 2016 11:09:02 -0400 Subject: Re: [PATCH/RFC 0/5] cpu_relax: introduce yield, remove lowlatency To: David Miller References: <1477051138-1610-1-git-send-email-borntraeger@de.ibm.com> <20161021.105727.140184460493941551.davem@davemloft.net> Cc: peterz@infradead.org, npiggin@gmail.com, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com, noamc@ezchip.com, virtualization@lists.linux-foundation.org, xen-devel@lists.xenproject.org, KVM list From: Christian Borntraeger Date: Fri, 21 Oct 2016 17:08:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161021.105727.140184460493941551.davem@davemloft.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16102115-0040-0000-0000-0000024AE936 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16102115-0041-0000-0000-00002243A96B Message-Id: <2cf23cb7-05c5-0a2d-2ed5-aa90d582f802@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-21_09:,, 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-1609300000 definitions=main-1610210274 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/21/2016 04:57 PM, David Miller wrote: > From: Christian Borntraeger > Date: Fri, 21 Oct 2016 13:58:53 +0200 > >> For spinning loops people did often use barrier() or cpu_relax(). >> For most architectures cpu_relax and barrier are the same, but on >> some architectures cpu_relax can add some latency. For example on s390 >> cpu_relax gives up the time slice to the hypervisor. On power cpu_relax >> tries to give some of the CPU to the neighbor threads. To reduce the >> latency another variant cpu_relax_lowlatency was introduced. Before this >> is used in more and more places, lets revert the logic of provide a new >> function cpu_relax_yield that can spend some time and for s390 yields >> the guest CPU. > > Sparc64, fwiw, behaves similarly to powerpc. As sparc currently defines cpu_relax_lowlatency to cpu_relax, this patch set should be a no-op then for sparc, correct? My intend was that cpu_relax should not add a huge latency but can certainly push some cpu power to hardware threads of the same core. This seems to be the case for sparc/power and some arc variants. Christian