Re: [PATCH v2 2/3] KVM: LAPIC: lapic timer interrupt is injected by posted interrupt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 11 Jun 2019 at 00:51, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote:
>
> 2019-06-06 13:31+0800, Wanpeng Li:
> > From: Wanpeng Li <wanpengli@xxxxxxxxxxx>
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> > There is no hardware virtual timer on Intel for guest like ARM. Both
> > programming timer in guest and the emulated timer fires incur vmexits.
> > This patch tries to avoid vmexit which is incurred by the emulated
> > timer fires in dedicated instance scenario.
> >
> > When nohz_full is enabled in dedicated instances scenario, the emulated
> > timers can be offload to the nearest busy housekeeping cpus since APICv
> > is really common in recent years. The guest timer interrupt is injected
> > by posted-interrupt which is delivered by housekeeping cpu once the emulated
> > timer fires.
> >
> > 3%~5% redis performance benefit can be observed on Skylake server.
> >
> > Signed-off-by: Wanpeng Li <wanpengli@xxxxxxxxxxx>
> > ---
> >  arch/x86/kvm/lapic.c | 32 +++++++++++++++++++++++++-------
> >  arch/x86/kvm/x86.h   |  5 +++++
> >  2 files changed, 30 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 09b7387..c08e5a8 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -133,6 +133,12 @@ static inline bool posted_interrupt_inject_timer_enabled(struct kvm_vcpu *vcpu)
> >               kvm_mwait_in_guest(vcpu->kvm);
> >  }
> >
> > +static inline bool can_posted_interrupt_inject_timer(struct kvm_vcpu *vcpu)
> > +{
> > +     return posted_interrupt_inject_timer_enabled(vcpu) &&
> > +             !vcpu_halt_in_guest(vcpu);
>
> It would make more sense to have a condition for general blocking in
> KVM, but keep in mind that we're not running on the same cpu anymore, so
> any code like that has to be properly protected against VM entries under
> our hands.  (The VCPU could appear halted here, but before we get make
> the timer pending, the VCPU would enter and potentially never check the
> interrupt.)
>
> I think we should be able to simply do
>
>   if (posted_interrupt_inject_timer_enabled(vcpu))
>         kvm_inject_apic_timer_irqs();
>
> directly in the apic_timer_expired() as the injection will wake up the
> target if necessary.  It's going to be a bit slow for timer callback in
> those (too slow to warrant special handling?), but there hopefully
> aren't any context restrictions in place.

The vCPU halt status is used to handle non-PV apf notification aware
guest which is pointed out by Paolo.
https://lkml.org/lkml/2019/6/5/436 The vCPU will not re-vmentry w/
timer interrupt even if there is a kick since vcpu->arch.apf.halted is
true and it can't escape from kvm_vcpu_check_block().

Regards,
Wanpeng Li




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux