| Message ID | 1645760664-26028-1-git-send-email-lirongqing@baidu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [resend] KVM: x86: Yield to IPI target vCPU only if it is busy | expand |
On Fri, 25 Feb 2022 at 23:04, Li RongQing <lirongqing@baidu.com> wrote: > > When sending a call-function IPI-many to vCPUs, yield to the > IPI target vCPU which is marked as preempted. > > but when emulating HLT, an idling vCPU will be voluntarily > scheduled out and mark as preempted from the guest kernel > perspective. yielding to idle vCPU is pointless and increase > unnecessary vmexit, maybe miss the true preempted vCPU > > so yield to IPI target vCPU only if vCPU is busy and preempted This is not correct, there is an intention to boost the reactivation of idle vCPU, PV sched yield is used in over-subscribe scenario and the pCPU which idle vCPU is resident maybe busy, and the vCPU will wait in the host scheduler run queue. There is a research paper [1] focusing on this boost and showing better performance numbers, though their boost is more unfair. [1]. https://ieeexplore.ieee.org/document/8526900 "Accelerating Idle vCPU Reactivation" Wanpeng
> On Fri, 25 Feb 2022 at 23:04, Li RongQing <lirongqing@baidu.com> wrote: > > > > When sending a call-function IPI-many to vCPUs, yield to the IPI > > target vCPU which is marked as preempted. > > > > but when emulating HLT, an idling vCPU will be voluntarily scheduled > > out and mark as preempted from the guest kernel perspective. yielding > > to idle vCPU is pointless and increase unnecessary vmexit, maybe miss > > the true preempted vCPU > > > > so yield to IPI target vCPU only if vCPU is busy and preempted > > This is not correct, there is an intention to boost the reactivation of idle vCPU, > PV sched yield is used in over-subscribe scenario and the pCPU which idle vCPU is > resident maybe busy, and the vCPU will wait in the host scheduler run queue. > There is a research paper [1] focusing on this boost and showing better > performance numbers, though their boost is more unfair. > > [1]. https://ieeexplore.ieee.org/document/8526900 > "Accelerating Idle vCPU Reactivation" > > Wanpeng I understand that over-subscribe system is not always over- subscribe, it should sometime true, sometime not. Without this patch, it will hard the performance when cpu is not over-subscribe. And yielding to a not ready vcpu is unnecessary as kvm_sched_yield static void kvm_sched_yield(struct kvm_vcpu *vcpu, unsigned long dest_id) { if (!target || !READ_ONCE(target->ready)) goto no_yield; } -Li
On Mon, 28 Feb 2022 at 09:27, Li,Rongqing <lirongqing@baidu.com> wrote: > > > On Fri, 25 Feb 2022 at 23:04, Li RongQing <lirongqing@baidu.com> wrote: > > > > > > When sending a call-function IPI-many to vCPUs, yield to the IPI > > > target vCPU which is marked as preempted. > > > > > > but when emulating HLT, an idling vCPU will be voluntarily scheduled > > > out and mark as preempted from the guest kernel perspective. yielding > > > to idle vCPU is pointless and increase unnecessary vmexit, maybe miss > > > the true preempted vCPU > > > > > > so yield to IPI target vCPU only if vCPU is busy and preempted > > > > This is not correct, there is an intention to boost the reactivation of idle vCPU, > > PV sched yield is used in over-subscribe scenario and the pCPU which idle vCPU is > > resident maybe busy, and the vCPU will wait in the host scheduler run queue. > > There is a research paper [1] focusing on this boost and showing better > > performance numbers, though their boost is more unfair. > > > > [1]. https://ieeexplore.ieee.org/document/8526900 > > "Accelerating Idle vCPU Reactivation" > > > > Wanpeng > > > I understand that over-subscribe system is not always over- subscribe, it should sometime true, sometime not. You should pay the pain if you do not tune your setup well. Wanpeng
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 355fe8b..58749f2 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; }
When sending a call-function IPI-many to vCPUs, yield to the IPI target vCPU which is marked as preempted. but when emulating HLT, an idling vCPU will be voluntarily scheduled out and mark as preempted from the guest kernel perspective. yielding to idle vCPU is pointless and increase unnecessary vmexit, maybe miss the true preempted vCPU so yield to IPI target vCPU only if vCPU is busy and preempted Signed-off-by: Li RongQing <lirongqing@baidu.com> --- arch/x86/kernel/kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)