Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp654002pxf; Thu, 8 Apr 2021 10:09:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxku2jxFHkPjoODjcOJwUnReV5WbI1zwLR1umicrK1C2U2ClRoSLsatnbWYNMoMBK3rUV2E X-Received: by 2002:a17:90b:4a81:: with SMTP id lp1mr9386764pjb.154.1617901771577; Thu, 08 Apr 2021 10:09:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617901771; cv=none; d=google.com; s=arc-20160816; b=iUa5CFT3WRrjHkPk4pORCO9+NtdMLlTfObxmk+EbjZliT1ka8kCAoJb0ZUBVIvzF4w 9lGXx6kyA6UGtaXppgdcXFmO/tRn+eu2/IolQ24UG0Wz8KgN1kDMqt/VTelTPIqHZDPU B8ChZOgyTrKeeUY58jMIhb07Z+l0hxCPF9O8EQBBfovrkoPsVDfA0eJmJ8vBCMiK1ZUo zcLHEQU3+SU9xyj4noHSDgUkBYhKBJDbBzq06ESQskJunxH/vDqRfEf+2lXCtqGtqCXh cCbIwBGwnGL7QrGOvdb7MTfjwpal1QZWo4vOxQM8ClnR9pA1Klocwy4sU5+mmSsR/5xn Dyyw== 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=lQ5FJuYAdemeQPR+BYJiVntd5fDu24NRSQN06r03aP4=; b=PlGE300aFy90V2ai6g9y/v69S3vsOEfoPs+ubWkV5U7URNMUZvA9XXcJvHumHE07pc x1GkkrVMoqpKNBz3RawLCoOul3VprOCeAigjQ/0Nl2ePN5nHWmXB7Gt7wCMzgOAmgIP6 ocHqptCY94MQUCoHvRlyxVIbKMhF9Lm4wEcTV9jH+7KgmxRz8O1TJOwZWCoC8FOHX7RT WeWpimVOkX+h0wqs95LW6+Ti0NCRUYPCnl+Gxji81loOTwo8lIUmlPKDFXxdPF4/pHeI 3QlkfgJTskmuqj++0m/Z3ejXiCUgaMyMym9L9PBjhIldWl6QZFVkKtDW+h792MKByTcN czHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=PBUU8Eag; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 29si666936pje.58.2021.04.08.10.09.18; Thu, 08 Apr 2021 10:09:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=PBUU8Eag; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S232435AbhDHRIu (ORCPT + 99 others); Thu, 8 Apr 2021 13:08:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231699AbhDHRIq (ORCPT ); Thu, 8 Apr 2021 13:08:46 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6229CC061761 for ; Thu, 8 Apr 2021 10:08:34 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id g10so1374129plt.8 for ; Thu, 08 Apr 2021 10:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lQ5FJuYAdemeQPR+BYJiVntd5fDu24NRSQN06r03aP4=; b=PBUU8Eag8Z8PXgTEmQcMaob7vxEJ7RtBcR3bdNaaNS1eB8n2lyXIyGH3hopYnFORoC h59cs9nf5xrWkQPffxCF3q4CsmqjFxRZFqhNMd8x+IEVDz4UE5fYB0v4H9r0LgYkejSJ ApTaviquOiS0H4Kj8z32bmUgOMDsydV3UXLqzAw+4neaHyyfeutIIEydbIJ9vnSoF/QM UQOGsaRqTFL0DmxmAiWFC7Bwlo8sm0UjGiNPd3W11BAidGxezBLXT2fPb3WrFz4eOh6R u+Pw6oC8sdzKlAeYTFbVjjPxmERS3p2fOUOB0GHznaFFGopCum3lIWIG8YsaiX9bgOIv gPFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lQ5FJuYAdemeQPR+BYJiVntd5fDu24NRSQN06r03aP4=; b=i5qDZdun9vqAuoLlg9/wIBjvoK0OlVsiFL+xeazg9XqPN+wucl30BTcZo9rnjF3VqT M7ip3utQqWefLNaN2oMUbic2vPb0I/gRzp7hfyt4oacB0prqBmXIYPHAofb+p/ZYyyoN ZC29BYjK3CyGOwc0ZIHDi0B2cq99MkasvWkdknWLRzlqcgmEshF/cGVv79YYHTPnttUg ysqzSZbQiDSh8q5jONfFFjQA7192YyW3HMp9XEn87ylDVhG7Qu4DObGx5AD2Hwuc4ugt bpaMaJ9cF4HIxb3+8sbggGOThXBbAosIeqPcmyf9ubeFsNuntQedpDbe9hzXADY6fCtf zfMA== X-Gm-Message-State: AOAM530JUEYFhxbzRpLhoCvp+3H5Y9NZNZo+jEOaqMJZdtztHdOspgmn 1R4JHEEFE1XQNPWPcFRJljkvvQ== X-Received: by 2002:a17:902:9a0a:b029:e6:bf00:8a36 with SMTP id v10-20020a1709029a0ab02900e6bf008a36mr8702094plp.51.1617901713728; Thu, 08 Apr 2021 10:08:33 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id x9sm53062pfd.158.2021.04.08.10.08.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 10:08:33 -0700 (PDT) Date: Thu, 8 Apr 2021 17:08:29 +0000 From: Sean Christopherson To: Wanpeng Li Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [PATCH] KVM: X86: Count success and invalid yields Message-ID: References: <1617697935-4158-1-git-send-email-wanpengli@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1617697935-4158-1-git-send-email-wanpengli@tencent.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 06, 2021, Wanpeng Li wrote: > From: Wanpeng Li > > To analyze some performance issues with lock contention and scheduling, > it is nice to know when directed yield are successful or failing. > > Signed-off-by: Wanpeng Li > --- > arch/x86/include/asm/kvm_host.h | 2 ++ > arch/x86/kvm/x86.c | 26 ++++++++++++++++++++------ > 2 files changed, 22 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index 44f8930..157bcaa 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1126,6 +1126,8 @@ struct kvm_vcpu_stat { > u64 halt_poll_success_ns; > u64 halt_poll_fail_ns; > u64 nested_run; > + u64 yield_directed; > + u64 yield_directed_ignore; > }; > > struct x86_instruction_info; > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 16fb395..3b475cd 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -246,6 +246,8 @@ struct kvm_stats_debugfs_item debugfs_entries[] = { > VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns), > VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns), > VCPU_STAT("nested_run", nested_run), > + VCPU_STAT("yield_directed", yield_directed), This is ambiguous, it's not clear without looking at the code if it's counting attempts or actual yields. > + VCPU_STAT("yield_directed_ignore", yield_directed_ignore), "ignored" also feels a bit misleading, as that implies KVM deliberately ignored a valid request, whereas many of the failure paths are due to invalid requests or errors of some kind. What about mirroring the halt poll stats, i.e. track "attempted" and "successful", as opposed to "attempted" and "ignored/failed". And maybe switched directed and yield? I.e. directed_yield_attempted and directed_yield_successful. Alternatively, would it make sense to do s/directed/pv, or is that not worth the potential risk of being wrong if a non-paravirt use case comes along? pv_yield_attempted pv_yield_successful > VM_STAT("mmu_shadow_zapped", mmu_shadow_zapped), > VM_STAT("mmu_pte_write", mmu_pte_write), > VM_STAT("mmu_pde_zapped", mmu_pde_zapped), > @@ -8211,21 +8213,33 @@ void kvm_apicv_init(struct kvm *kvm, bool enable) > } > EXPORT_SYMBOL_GPL(kvm_apicv_init); > > -static void kvm_sched_yield(struct kvm *kvm, unsigned long dest_id) > +static void kvm_sched_yield(struct kvm_vcpu *vcpu, unsigned long dest_id) > { > struct kvm_vcpu *target = NULL; > struct kvm_apic_map *map; > > + vcpu->stat.yield_directed++; > + > rcu_read_lock(); > - map = rcu_dereference(kvm->arch.apic_map); > + map = rcu_dereference(vcpu->kvm->arch.apic_map); > > if (likely(map) && dest_id <= map->max_apic_id && map->phys_map[dest_id]) > target = map->phys_map[dest_id]->vcpu; > > rcu_read_unlock(); > + if (!target) > + goto no_yield; > + > + if (!READ_ONCE(target->ready)) I vote to keep these checks together. That'll also make the addition of the "don't yield to self" check match the order of ready vs. self in kvm_vcpu_on_spin(). if (!target || !READ_ONCE(target->ready)) > + goto no_yield; > > - if (target && READ_ONCE(target->ready)) > - kvm_vcpu_yield_to(target); > + if (kvm_vcpu_yield_to(target) <= 0) > + goto no_yield; > + return; > + > +no_yield: > + vcpu->stat.yield_directed_ignore++; > + return; > } > > int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > @@ -8272,7 +8286,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > break; > > kvm_pv_kick_cpu_op(vcpu->kvm, a0, a1); > - kvm_sched_yield(vcpu->kvm, a1); > + kvm_sched_yield(vcpu, a1); > ret = 0; > break; > #ifdef CONFIG_X86_64 > @@ -8290,7 +8304,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > if (!guest_pv_has(vcpu, KVM_FEATURE_PV_SCHED_YIELD)) > break; > > - kvm_sched_yield(vcpu->kvm, a0); > + kvm_sched_yield(vcpu, a0); > ret = 0; > break; > default: > -- > 2.7.4 >