Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp653560ybp; Fri, 11 Oct 2019 02:06:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqwyk3yfQJH5c3t7Eq8sMxbLXIWPVegkhKUGyjtAkcFIMdgI4lq33dxIqtHzSQUPM8+KYyAb X-Received: by 2002:a05:6402:14d6:: with SMTP id f22mr12755658edx.148.1570784791617; Fri, 11 Oct 2019 02:06:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570784791; cv=none; d=google.com; s=arc-20160816; b=npEmznUJdTvTHTo0Ok2M/C6h8qdCY4njq4rulmmUTm/zAkx13anViqC8O8/9cql8hX ZDIrANMLYxsDfKQSSm4DFLoW7xEKypWlFu4uZHnQF8hzHqH0M4IQ0kd02LCAu/qUqv7H BxMN5Z4EDb6ukbfv17f5UYjaPcR+rbjKD8n6BaDkvToU37cdRwI3mpzS9DSfzRTtDhWN fvraDrcnFnMo4pkiU14RQLi//z1TB+CI/NJ3HMevTybAw4LKRndjaoWG9ERQGU1jfWu/ 7gC/bkwrKqcZzDvGa8zR2drruij2oflwRqppqAYrml4yVFpSJGt7X+T55Xg+XvErppkM V+qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=VCUUGxMLO8nDv9SzmYQ0wxPR/iZuwoS7QOBqeDNcZ18=; b=BpoeqTLSDAO0cQukPihM7bN5Gv9zu4SMTmESd3YwuZBic8BniB++Gn7CCf8ZtTfVZF 3PwmrcsvxYB2rAS/TZ/G2aIM4SD4pllFm4Wm8L0kdWRtwelsjR2cuPUptgt6YwtVSibl bHTtAsJBU9mVQmsxfzmf3g4VDKT9O3R8otvO4o993qHtW6faiDcvW6jfxMJX2oht4gRo RKEqNxXq5T1E3x6EMI/2LuZ7YoqnFtv+VHPyj9k7AhBloiNGffSX8n2fZ93IcHw6P7c1 7my2xBEzryCd1zDvjw0iy1Xrt+aSMMlnQVERHV1HoXe9yaz24HMSNgVMiJ6SU9PMij6t GILg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w43si5694867edd.332.2019.10.11.02.06.08; Fri, 11 Oct 2019 02:06:31 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727554AbfJKJFT (ORCPT + 99 others); Fri, 11 Oct 2019 05:05:19 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:51448 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726948AbfJKJFT (ORCPT ); Fri, 11 Oct 2019 05:05:19 -0400 Received: from 79.184.255.36.ipv4.supernova.orange.pl (79.184.255.36) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.292) id 903db73bb3920c92; Fri, 11 Oct 2019 11:05:17 +0200 From: "Rafael J. Wysocki" To: Yin Fengwei Cc: Len Brown , "open list:ACPI" , open list Subject: Re: [RESEND] ACPI / processor_idle: use dead loop instead of io port access for wait Date: Fri, 11 Oct 2019 11:05:16 +0200 Message-ID: <12278756.3dKznOqol2@kreacher> In-Reply-To: <20190909073937.31554-1-fengwei.yin@intel.com> References: <20190909073937.31554-1-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry for the delay. On Monday, September 9, 2019 9:39:37 AM CEST Yin Fengwei wrote: > In function acpi_idle_do_entry(), we do an io port access to guarantee > hardware behavior. But it could trigger unnecessary vmexit for > virtualization environemnt. Is this a theoretical problem, or do you actually see it? If you see it, I'd like to have a pointer to a bug report regarding it or similar. > From the comments of this part of code, we could use busy wait instead > of io port access to guarantee hardware behavior and avoid unnecessary > vmexit. > > Signed-off-by: Yin Fengwei > --- > drivers/acpi/processor_idle.c | 33 ++++++++++++++++++++++++++++++--- > 1 file changed, 30 insertions(+), 3 deletions(-) > > diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c > index ed56c6d20b08..676553228e8f 100644 > --- a/drivers/acpi/processor_idle.c > +++ b/drivers/acpi/processor_idle.c > @@ -55,6 +55,8 @@ struct cpuidle_driver acpi_idle_driver = { > }; > > #ifdef CONFIG_ACPI_PROCESSOR_CSTATE > +static struct timespec64 dummy_delta = {0L, 0L}; > + > static > DEFINE_PER_CPU(struct acpi_processor_cx * [CPUIDLE_STATE_MAX], acpi_cstate); > > @@ -64,6 +66,18 @@ static int disabled_by_idle_boot_param(void) > boot_option_idle_override == IDLE_HALT; > } > > +static void dummy_wait(void) > +{ > + struct timespec64 now, target; > + > + ktime_get_real_ts64(&now); > + target = timespec64_add(now, dummy_delta); > + > + do { > + ktime_get_real_ts64(&now); > + } while (timespec64_compare(&now, &target) < 0); > +} Why not to use ndelay() instead of this? -> > + > /* > * IBM ThinkPad R40e crashes mysteriously when going into C2 or C3. > * For now disable this. Probably a bug somewhere else. > @@ -660,8 +674,12 @@ static void __cpuidle acpi_idle_do_entry(struct acpi_processor_cx *cx) > inb(cx->address); > /* Dummy wait op - must do something useless after P_LVL2 read > because chipsets cannot guarantee that STPCLK# signal > - gets asserted in time to freeze execution properly. */ > - inl(acpi_gbl_FADT.xpm_timer_block.address); > + gets asserted in time to freeze execution properly. > + > + Previously, we do io port access here which could trigger > + unnecessary trap to HV for virtualization env. We use dead > + loop here to avoid the impact to virtualization env. */ > + dummy_wait(); > } > } > > @@ -683,7 +701,7 @@ static int acpi_idle_play_dead(struct cpuidle_device *dev, int index) > else if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) { > inb(cx->address); > /* See comment in acpi_idle_do_entry() */ > - inl(acpi_gbl_FADT.xpm_timer_block.address); > + dummy_wait(); > } else > return -ENODEV; > } > @@ -902,6 +920,7 @@ static inline void acpi_processor_cstate_first_run_checks(void) > { > acpi_status status; > static int first_run; > + struct timespec64 ts0, ts1; > > if (first_run) > return; > @@ -912,6 +931,13 @@ static inline void acpi_processor_cstate_first_run_checks(void) > max_cstate); > first_run++; > > + /* profiling the time used for dummy wait op */ > + ktime_get_real_ts64(&ts0); > + inl(acpi_gbl_FADT.xpm_timer_block.address); > + ktime_get_real_ts64(&ts1); -> And simply measure the number of nsecs this takes? > + > + dummy_delta = timespec64_sub(ts1, ts0); > + > if (acpi_gbl_FADT.cst_control && !nocst) { > status = acpi_os_write_port(acpi_gbl_FADT.smi_command, > acpi_gbl_FADT.cst_control, 8); > @@ -920,6 +946,7 @@ static inline void acpi_processor_cstate_first_run_checks(void) > "Notifying BIOS of _CST ability failed")); > } > } > + > #else > > static inline int disabled_by_idle_boot_param(void) { return 0; } >