Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp298750ybf; Wed, 26 Feb 2020 13:22:58 -0800 (PST) X-Google-Smtp-Source: APXvYqzsGKStkhz0IJtwwkl8ttWBRHhdaJ7pPWOz4AcahcPtwll4DrypoP22cb8rX77CTxrToqL3 X-Received: by 2002:a05:6808:b23:: with SMTP id t3mr843812oij.88.1582752178461; Wed, 26 Feb 2020 13:22:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582752178; cv=none; d=google.com; s=arc-20160816; b=dbViAzYGXd7+ru8n2pAXut/bWFpj/TTrKYbHXQ8FrUuTDhfegOVQMPY/gSEv4XVpBF HaUkFhWab1J8XHEhFdP28F3SbLY/67o9DSPJSB68Kb9mTbyzSt9M2w52RH+V8rzjEV2V JQU6Cezf0fXMSiZ/auMJzZuixpwn5f8c9zV18ei5MZdjFbFuEtwaZDTR4U8u6c5GfTt+ tUw+zkjq/k4R6UymsLfODv+/fe6PdkI48lzbAYY87HKwULto0pYd2QrS5aXP7MAOde/9 TUTJYxy5olntC1+8rr93o0Es7WuyiW9qhm4Va2+i7f1ZigsCr5rRnnf5hDDX5vf4stCf pQew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Fg3+/uyd93DmMnDVD+QSPwDwsR/xA1CQ39M8KWCCOn8=; b=gV0jXdQjINMBy5ihLxKLcUJE3u+FZ8TASMkULesPfZcgycAwiz6eWfnbp9nEF4b9cC TibHEuwf1dDQhaGnKzPydj6bdWlbrIp1EpGGBc5GczaFOYVY+ToTmDFCS6mCmIRCk+Yf 7O+fyexorwQjFQcD1jVnFqG3W6A0gbLvxvJtmXC75hVm76x1X2qRLjmqUEsx2sb+Cv+U w0LjOUhUfzcmlsrmS5Yv46P73KyVRyEbw3PNeZX8jMXd7np79Z4dgjg99mKzMUZUr3yB yMe+G8m62CkEDt08J5273a3tqpY7763kKnYK358LQbdkK8ggHOL6ue5hkHUh3pDJuN56 sPLA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j15si194415oie.15.2020.02.26.13.22.46; Wed, 26 Feb 2020 13:22:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727593AbgBZVVf (ORCPT + 99 others); Wed, 26 Feb 2020 16:21:35 -0500 Received: from mga18.intel.com ([134.134.136.126]:13577 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727503AbgBZVVf (ORCPT ); Wed, 26 Feb 2020 16:21:35 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 13:21:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,489,1574150400"; d="scan'208";a="350484102" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by fmsmga001.fm.intel.com with ESMTP; 26 Feb 2020 13:21:33 -0800 Date: Wed, 26 Feb 2020 13:31:11 -0800 From: Fenghua Yu To: Andi Kleen Cc: Kyung Min Park , x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, gregkh@linuxfoundation.org, tony.luck@intel.com, ashok.raj@intel.com, ravi.v.shankar@intel.com Subject: Re: [PATCH 2/2] x86/asm/delay: Introduce TPAUSE delay Message-ID: <20200226213111.GB113541@romley-ivt3.sc.intel.com> References: <1582744258-42744-1-git-send-email-kyung.min.park@intel.com> <1582744258-42744-3-git-send-email-kyung.min.park@intel.com> <20200226211040.GS160988@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200226211040.GS160988@tassilo.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 26, 2020 at 01:10:40PM -0800, Andi Kleen wrote: > On Wed, Feb 26, 2020 at 11:10:58AM -0800, Kyung Min Park wrote: > > TPAUSE instructs the processor to enter an implementation-dependent > > optimized state. The instruction execution wakes up when the time-stamp > > counter reaches or exceeds the implicit EDX:EAX 64-bit input value. > > The instruction execution also wakes up due to the expiration of > > the operating system time-limit or by an external interrupt > > This is actually a behavior change. Today's udelay() will continue > after processing the interrupt. Your patches don't > > I don't think it's a problem though. The interrupt will cause > a long enough delay that exceed any reasonable udelay() requirements. > > There would be a difference if someone did really long udelay()s, much > longer than typical interrupts, in this case you might end up > with a truncated udelay, but such long udelays are not something that we > would encourage. TPAUSE is in a loop which checks if this udelay exceeds deadline. Coming back from interrupt, the loop checks deadline and finds there is still left time to delay. Then udelay() goes back to TPAUSE. Thanks. -Fenghua