From patchwork Sun Feb 6 13:42:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Li RongQing X-Patchwork-Id: 12736542 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 15B93C433F5 for ; Sun, 6 Feb 2022 13:42:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239974AbiBFNma (ORCPT ); Sun, 6 Feb 2022 08:42:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239964AbiBFNm3 (ORCPT ); Sun, 6 Feb 2022 08:42:29 -0500 X-Greylist: delayed 8177 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sun, 06 Feb 2022 05:42:27 PST Received: from baidu.com (mx24.baidu.com [111.206.215.185]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 60C23C043183 for ; Sun, 6 Feb 2022 05:42:27 -0800 (PST) Received: from BC-Mail-Ex16.internal.baidu.com (unknown [172.31.51.56]) by Forcepoint Email with ESMTPS id 1D8B49227D940A4670D2; Sun, 6 Feb 2022 21:42:15 +0800 (CST) Received: from BJHW-Mail-Ex15.internal.baidu.com (10.127.64.38) by BC-Mail-Ex16.internal.baidu.com (172.31.51.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Sun, 6 Feb 2022 21:42:14 +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; Sun, 6 Feb 2022 21:42:14 +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" Subject: =?eucgb2312_cn?b?tPC4tDogW1BBVENIXSBLVk06IFg4Njogc2V0IHZjcHUgcHJlZW1wdGVk?= =?eucgb2312_cn?b?IG9ubHkgaWYgaXQgaXMgcHJlZW1wdGVk?= Thread-Topic: [PATCH] KVM: X86: set vcpu preempted only if it is preempted Thread-Index: AQHYB7WMg7j2vnvXFkKy6dq5PabOWqxfHr2AgABDQICAJyN4QIAAKHmw Date: Sun, 6 Feb 2022 13:42:14 +0000 Message-ID: <39f8f0f26c5b453ba61e8c8256955eae@baidu.com> References: <1641988921-3507-1-git-send-email-lirongqing@baidu.com> <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: [10.14.117.122] MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org > > 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 tihnk. > > > If vcpu is idle, and be marked as preempted, is it right in > kvm_smp_send_call_func_ipi? > > static void kvm_smp_send_call_func_ipi(const struct cpumask *mask) { > int cpu; > > native_send_call_func_ipi(mask); > > /* Make sure other vCPUs get a chance to run if they need to. */ > for_each_cpu(cpu, mask) { > if (vcpu_is_preempted(cpu)) { > kvm_hypercall1(KVM_HC_SCHED_YIELD, > per_cpu(x86_cpu_to_apicid, cpu)); > break; > } > } > } > Check if vcpu is idle before check vcpu is preempted? Similar in kvm_flush_tlb_multi() ? -Li diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index fe0aead..c1ebd69 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -619,7 +619,7 @@ static void kvm_smp_send_call_func_ipi(const struct cpumask *mask) /* Make sure other vCPUs get a chance to run if they need to. */ for_each_cpu(cpu, mask) { - if (vcpu_is_preempted(cpu)) { + if (!idle_cpu(cpu) && vcpu_is_preempted(cpu)) { kvm_hypercall1(KVM_HC_SCHED_YIELD, per_cpu(x86_cpu_to_apicid, cpu)); break; }