From: Sean Christopherson <seanjc@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Li RongQing <lirongqing@baidu.com>,
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: Re: [PATCH] KVM: X86: set vcpu preempted only if it is preempted
Date: Wed, 12 Jan 2022 17:30:47 +0000 [thread overview]
Message-ID: <Yd8QR2KHDfsekvNg@google.com> (raw)
In-Reply-To: <Yd7S5rEYZg8v93NX@hirez.programming.kicks-ass.net>
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".
The lack of a vcpu->preempted check has confused me for a long time. I assumed
that was intended behavior, but looking at the original commit, I'm not so sure.
The changelog is somewhat contradictory, as the the last sentence says "is running
or not", but I suspect that's just imprecise language.
commit 0b9f6c4615c993d2b552e0d2bd1ade49b56e5beb
Author: Pan Xinhui <xinhui.pan@linux.vnet.ibm.com>
Date: Wed Nov 2 05:08:35 2016 -0400
x86/kvm: Support the vCPU preemption check
Support the vcpu_is_preempted() functionality under KVM. This will
enhance lock performance on overcommitted hosts (more runnable vCPUs
than physical CPUs in the system) as doing busy waits for preempted
vCPUs will hurt system performance far worse than early yielding.
Use struct kvm_steal_time::preempted to indicate that if a vCPU
is running or not.
vcpu->preempted will be set if KVM schedules out the vCPU to service _TIF_NEED_RESCHED,
but not in the HLT case because KVM will mark the vCPU as TASK_INTERRUPTIBLE. The
flag also won't be set if KVM puts the vCPU when exiting to userspace to handle I/O
or whatever, which is also desirable from the guest's perspective.
There might be potential for false negatives, but any damage there is likely
far outweighed by getting false positives, especially in the HLT case.
So somewhat tentatively...
Reviewed-by: Sean Christopherson <seanjc@google.com>
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > Signed-off-by: Wang GuangJu <wangguangju@baidu.com>
> > ---
> > arch/x86/kvm/x86.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 9f5dbf7..10d76bf 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -4407,6 +4407,9 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
> > if (vcpu->arch.st.preempted)
> > return;
> >
> > + if (!vcpu->preempted)
> > + return;
> > +
> > /* This happens on process exit */
> > if (unlikely(current->mm != vcpu->kvm->mm))
> > return;
> > --
> > 2.9.4
> >
next prev parent reply other threads:[~2022-01-12 17:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 12:02 [PATCH] KVM: X86: set vcpu preempted only if it is preempted Li RongQing
2022-01-12 13:08 ` Peter Zijlstra
2022-01-12 17:30 ` Sean Christopherson [this message]
2022-01-12 18:44 ` Paolo Bonzini
2022-01-12 19:07 ` Sean Christopherson
2022-01-12 21:31 ` Peter Zijlstra
2022-01-13 4:52 ` 答复: " Li,Rongqing
2022-01-13 9:33 ` Peter Zijlstra
2022-01-13 11:55 ` 答复: " Li,Rongqing
2022-01-13 12:48 ` Wanpeng Li
2022-01-14 9:58 ` 答复: " Li,Rongqing
2022-01-13 16:34 ` Sean Christopherson
2022-02-06 11:23 ` 答复: " Li,Rongqing
2022-02-06 13:42 ` Li,Rongqing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yd8QR2KHDfsekvNg@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.