From patchwork Thu Jan 13 04:52:40 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Li RongQing X-Patchwork-Id: 12712299 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36063C433F5 for ; Thu, 13 Jan 2022 05:08:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229517AbiAMFIx (ORCPT ); Thu, 13 Jan 2022 00:08:53 -0500 Received: from mx24.baidu.com ([111.206.215.185]:35832 "EHLO baidu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229456AbiAMFIw (ORCPT ); Thu, 13 Jan 2022 00:08:52 -0500 Received: from BJHW-Mail-Ex12.internal.baidu.com (unknown [10.127.64.35]) by Forcepoint Email with ESMTPS id D0CF2F038D8C2C6EE0B5; Thu, 13 Jan 2022 12:52:40 +0800 (CST) Received: from bjkjy-mail-ex25.internal.baidu.com (172.31.50.41) by BJHW-Mail-Ex12.internal.baidu.com (10.127.64.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Thu, 13 Jan 2022 12:52:40 +0800 Received: from BJHW-Mail-Ex15.internal.baidu.com (10.127.64.38) by bjkjy-mail-ex25.internal.baidu.com (172.31.50.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.17; Thu, 13 Jan 2022 12:52:40 +0800 Received: from BJHW-Mail-Ex15.internal.baidu.com ([100.100.100.38]) by BJHW-Mail-Ex15.internal.baidu.com ([100.100.100.38]) with mapi id 15.01.2308.020; Thu, 13 Jan 2022 12:52:40 +0800 From: "Li,Rongqing" To: Peter Zijlstra , Sean Christopherson CC: "pbonzini@redhat.com" , "vkuznets@redhat.com" , "wanpengli@tencent.com" , "jmattson@google.com" , "tglx@linutronix.de" , "bp@alien8.de" , "x86@kernel.org" , "kvm@vger.kernel.org" , "joro@8bytes.org" , "Wang,Guangju" Subject: =?eucgb2312_cn?b?tPC4tDogW1BBVENIXSBLVk06IFg4Njogc2V0IHZjcHUgcHJlZW1wdGVk?= =?eucgb2312_cn?b?IG9ubHkgaWYgaXQgaXMgcHJlZW1wdGVk?= Thread-Topic: [PATCH] KVM: X86: set vcpu preempted only if it is preempted Thread-Index: AQHYB7WMg7j2vnvXFkKy6dq5PabOWqxfHr2AgABDQICAAPSkQA== Date: Thu, 13 Jan 2022 04:52:40 +0000 Message-ID: References: <1641988921-3507-1-git-send-email-lirongqing@baidu.com> <20220112213129.GO16608@worktop.programming.kicks-ass.net> In-Reply-To: <20220112213129.GO16608@worktop.programming.kicks-ass.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.206.28] MIME-Version: 1.0 X-Baidu-BdMsfe-DateCheck: 1_BJHW-Mail-Ex12_2022-01-13 12:52:40:847 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org > -----邮件原件----- > 发件人: Peter Zijlstra > 发送时间: 2022年1月13日 5:31 > 收件人: Sean Christopherson > 抄送: Li,Rongqing ; pbonzini@redhat.com; > vkuznets@redhat.com; wanpengli@tencent.com; jmattson@google.com; > tglx@linutronix.de; bp@alien8.de; x86@kernel.org; kvm@vger.kernel.org; > joro@8bytes.org > 主题: Re: [PATCH] KVM: X86: set vcpu preempted only if it is preempted > > On Wed, Jan 12, 2022 at 05:30:47PM +0000, Sean Christopherson wrote: > > On Wed, Jan 12, 2022, Peter Zijlstra wrote: > > > On Wed, Jan 12, 2022 at 08:02:01PM +0800, Li RongQing wrote: > > > > vcpu can schedule out when run halt instruction, and set itself to > > > > INTERRUPTIBLE and switch to idle thread, vcpu should not be set > > > > preempted for this condition > > > > > > Uhhmm, why not? Who says the vcpu will run the moment it becomes > > > runnable again? Another task could be woken up meanwhile occupying > > > the real cpu. > > > > Hrm, but when emulating HLT, e.g. for an idling vCPU, KVM will > > voluntarily schedule out the vCPU and mark it as preempted from the > > guest's perspective. The vast majority, probably all, usage of > > steal_time.preempted expects it to truly mean "preempted" as opposed to > "not running". > > No, the original use-case was locking and that really cares about running. > > If the vCPU isn't running, we must not busy-wait for it etc.. > > Similar to the scheduler use of it, if the vCPU isn't running, we should not > consider it so. Getting the vCPU task scheduled back on the CPU can take a 'long' > time. > > If you have pinned vCPU threads and no overcommit, we have other knobs to > indicate this I think. Is it possible if guest has KVM_HINTS_REALTIME feature, but its HLT instruction is emulated by KVM? If it is possible, this condition has been performance degradation, since vcpu_is_preempted is not __kvm_vcpu_is_preempted, will return false. Similar, guest has nopvspin, but HLT instruction is emulated; Should we adjust the setting of pv_ops.lock.vcpu_is_preempted as below And I see the performance boost when guest has nopvspin, but HLT instruction is emulated with below change -Li diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 59abbda..b061d17 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -1048,6 +1048,11 @@ void __init kvm_spinlock_init(void) return; } + if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) { + pv_ops.lock.vcpu_is_preempted = + PV_CALLEE_SAVE(__kvm_vcpu_is_preempted); + } + /* * Disable PV spinlocks and use native qspinlock when dedicated pCPUs * are available. @@ -1076,10 +1081,6 @@ void __init kvm_spinlock_init(void) pv_ops.lock.wait = kvm_wait; pv_ops.lock.kick = kvm_kick_cpu; - if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) { - pv_ops.lock.vcpu_is_preempted = - PV_CALLEE_SAVE(__kvm_vcpu_is_preempted); - } /* * When PV spinlock is enabled which is preferred over * virt_spin_lock(), virt_spin_lock_key's value is meaningless.