Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1334916rwb; Fri, 7 Oct 2022 11:03:33 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6oQEAea1gDWHl0i++1QD8AdJRL9+Cmt9mbyN93DT5016y36h8SeyHfO5K0QmBqRdzAC34O X-Received: by 2002:a17:907:628f:b0:72f:58fc:3815 with SMTP id nd15-20020a170907628f00b0072f58fc3815mr5026253ejc.719.1665165813720; Fri, 07 Oct 2022 11:03:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665165813; cv=none; d=google.com; s=arc-20160816; b=ny1hVAiFyQvEU7+bNvP4J7QXmVBmBZR1ANeHBAb7GawBxjz2KQNrdNqkdDdK/UCu35 yZtZWQ8Ch6DDF5ALP4ErAYaTCGwZFGbfHk03xC85pVkRr7PysnEkqvk20n9ednoqE1CA oCjKcYy7SGBn+cf5elugCpZuvvuHXlN1EIWNlCzXORr7R4J+3Cknt17IiBIkXEQJKVox TY4BnVeBAk/bXeYAwQ+DrpWmZ81uX24QQGrn6nLpy8GIWAJwmmNMbayuQxkpE4NRLiG+ ZAejjZS15l0NGA2xdZnkr9Y0zQK2VZGkrnauJOzlxwzMnZ4GFz16y55B9fLORMZOEOUB pQfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=1lRmPL17ewK5r7v4/Z5wcorFNGfrrBdSgDO7MWGkQEg=; b=YZUZu9epnw6QZ5bpWW7lURjU7woml+9PPOyee2pxnm9QPnGVxDWeuleDCoMlawYjai vyZGOadFzit5qMpyihKKh4yinEHmeM1DU1GTMk80JTGpVyt24/lgVNRhNukGmLGE/tdC BV9WpS4riynHxdvccVw3Bd6ae+akx2b2xvnK6zXr2UkQTUZrPSlkyvBs4x56oO7adkRG QV176os3IsFY/VRQ7iDtk0KFVrhna9jmhgJo5d1br95Pz7G6eM7ax/Xy8x1yVPEfx1yZ 6OcL6Gl1/fYTa4QPhioGoCdPEzbg2EtcWcr+L6znsR2t0C5qEwlEE5zMxse2NOvQdWOA 1DLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=gxpxA5Y1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a12-20020a17090640cc00b007825337afeesi2438720ejk.273.2022.10.07.11.03.06; Fri, 07 Oct 2022 11:03:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=gxpxA5Y1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229748AbiJGRvp (ORCPT + 99 others); Fri, 7 Oct 2022 13:51:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229689AbiJGRvn (ORCPT ); Fri, 7 Oct 2022 13:51:43 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61E60D25AE for ; Fri, 7 Oct 2022 10:51:42 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id c24so5178545pls.9 for ; Fri, 07 Oct 2022 10:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1lRmPL17ewK5r7v4/Z5wcorFNGfrrBdSgDO7MWGkQEg=; b=gxpxA5Y1bjH0g6B+S6aB5V1jKYPn4lfH/Xc+8h1IW/23TzX0TrkOQgzQT9XjRjNHb4 9gtI9i9tzwaGJ3bec5ZGElmaVkFLmqXPLd7eZNOs/MsJeaDRHDaVVnVfG8mzLyf87xuT cRfm6P8y2b87GvvTKkQRpp91tixHfxihtpGS79Kpx6bQmQ2uBK0Wnd8ZsdYRCs+5Ex0j M2kb8UmgaLzSgRpD49o40wVX2fMGgXk2iZNg7Ho0R0vIKRbD2z/DhNn1WdC6IZ2q0hPv awPBlC0/TrOaOyCciM6chHMX7/fox/jEkDq4pRWKCZqTjOluO2BOkZyw3AStz0ecaM0m JiVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1lRmPL17ewK5r7v4/Z5wcorFNGfrrBdSgDO7MWGkQEg=; b=iWZjW1Ib9t+k2SEUdznDO8AjAKksMbkCnmVJ6XU9gcEb3Vz+uVjQPm6lkPUeq6jFNT LXXlSlIwkIErJTQPlDKbOpKpYTVJbV+v+BCBX0/5RlhaSB6CxsePgXMIgJoNIFKLAhww U0XCJ+Knx1Tb4gIAgaugxbgpgzHR0I9mmFi/5pumdNOm9a0OWc6gMLnxOKAFGcngFmmJ jWsX7EI7h+vLlT3Nz9HBS5TzEi/1F8t1cOHIia3vOImbE1FQNKezGViUf9qr+RLwT5ZI ajvvVGZ0tnH1DHY01iWo7tKTtx1gYdZVLczWa4pOOUfr0c90Jybfz4x9qg+RnAzl/M3c bGFw== X-Gm-Message-State: ACrzQf0br4aSebmQcamvIixnvhIAyvebiyc2gTTTuuAg+PdMN7B/1u5F tiKPDrAGKIA/uji5lxzivLqmdSmKibjqPg== X-Received: by 2002:a17:902:e8ca:b0:17f:764c:740f with SMTP id v10-20020a170902e8ca00b0017f764c740fmr6015816plg.51.1665165101675; Fri, 07 Oct 2022 10:51:41 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id h2-20020a63f902000000b00438834b14a1sm1914025pgi.80.2022.10.07.10.51.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Oct 2022 10:51:40 -0700 (PDT) Date: Fri, 7 Oct 2022 17:51:36 +0000 From: Sean Christopherson To: Dapeng Mi Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, zhenyuw@linux.intel.com Subject: Re: [PATCH] KVM: x86: disable halt polling when powersave governor is used Message-ID: References: <20220915073121.1038840-1-dapeng1.mi@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220915073121.1038840-1-dapeng1.mi@intel.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 15, 2022, Dapeng Mi wrote: > Halt polling is enabled by default even through the CPU frequency > governor is configured to powersave. Generally halt polling would > consume extra power and this's not identical with the intent of > powersave governor. > > disabling halt polling in powersave governor can save the precious > power in power critical case. > > FIO random read test on Alder Lake platform shows halt polling > occupies ~17% CPU utilization and consume 7% extra CPU power. > After disabling halt polling, CPU has more chance to enter deeper > C-states (C1E%: 25.3% -> 33.4%, C10%: 4.4% -> 17.4%). > > On Alder Lake platform, we don't find there are obvious performance > downgrade after disabling halt polling on FIO and Netperf cases. > Netperf UDP_RR case runs from two VMs locate on two different physical > machines. > > FIO(MB/s) Base Disable-halt-polling Delta% > Rand-read 432.6 436.3 0.8% > > Netperf Base Disable-halt-polling Delta% > UDP_RR 509.8 508.5 -0.3% > > Signed-off-by: Dapeng Mi > --- > arch/x86/kvm/x86.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index d7374d768296..c0eb6574cbbb 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -13015,7 +13015,22 @@ bool kvm_vector_hashing_enabled(void) > > bool kvm_arch_no_poll(struct kvm_vcpu *vcpu) > { > - return (vcpu->arch.msr_kvm_poll_control & 1) == 0; > + struct cpufreq_policy *policy = cpufreq_cpu_get(vcpu->cpu); Preemption is not disabled at this point, which means that using vcpu->cpu is potentially unsafe. Given that cpufreq is refcounting the returned object, I gotta imaging get migrated to a different pCPU would be problematic. > + bool powersave = false; I don't see anything in here that's x86 specific. Unless I'm missing something, this belongs in common KVM. > + > + /* > + * Halt polling could consume much CPU power, if CPU frequency > + * governor is set to "powersave", disable halt polling. > + */ > + if (policy) { > + if ((policy->policy == CPUFREQ_POLICY_POWERSAVE) || > + (policy->governor && Indentation is messed up. > + !strncmp(policy->governor->name, "powersave", KVM should not be comparing magic strings. If the cpufreq subsystem can't get policy->policy right, then that needs to be fixed. > + CPUFREQ_NAME_LEN))) > + powersave = true; > + cpufreq_cpu_put(policy); > + } > + return ((vcpu->arch.msr_kvm_poll_control & 1) == 0) || powersave; Doing all of the above work if polling is disabled is silly. > } > EXPORT_SYMBOL_GPL(kvm_arch_no_poll); All in all, _if_ we want to do this automatically and not let userspace decide how to manage powersave vs. halt-poll, I think this should be more like: --- virt/kvm/kvm_main.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e30f1b4ecfa5..01116859cb31 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -3483,6 +3484,23 @@ static inline void update_halt_poll_stats(struct kvm_vcpu *vcpu, ktime_t start, } } +static bool kvm_cpufreq_no_halt_poll(struct kvm_vcpu *vcpu) +{ + struct cpufreq_policy *policy; + bool powersave = false; + + preempt_disable(); + + policy = cpufreq_cpu_get(vcpu->cpu); + if (policy) { + powersave = (policy->policy == CPUFREQ_POLICY_POWERSAVE); + cpufreq_cpu_put(policy); + } + + preempt_enable(); + return powersave; +} + /* * Emulate a vCPU halt condition, e.g. HLT on x86, WFI on arm, etc... If halt * polling is enabled, busy wait for a short time before blocking to avoid the @@ -3491,7 +3509,8 @@ static inline void update_halt_poll_stats(struct kvm_vcpu *vcpu, ktime_t start, */ void kvm_vcpu_halt(struct kvm_vcpu *vcpu) { - bool halt_poll_allowed = !kvm_arch_no_poll(vcpu); + const bool halt_poll_allowed = !kvm_arch_no_poll(vcpu) && + !kvm_cpufreq_no_halt_poll(vcpu); bool do_halt_poll = halt_poll_allowed && vcpu->halt_poll_ns; ktime_t start, cur, poll_end; bool waited = false; base-commit: e18d6152ff0f41b7f01f9817372022df04e0d354 --