Re: [RFC PATCH 0/5] Utilizing VMX preemption for timer virtualization

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

 



GOn Fri, May 20, 2016 at 10:18:47PM +0000, Jiang, Yunhong wrote:
> 
> 
> > -----Original Message-----
> > From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] On
> > Behalf Of Marcelo Tosatti
> > Sent: Friday, May 20, 2016 11:19 AM
> > To: Yunhong Jiang <yunhong.jiang@xxxxxxxxxxxxxxx>
> > Cc: kvm@xxxxxxxxxxxxxxx; rkrcmar@xxxxxxxxxx; pbonzini@xxxxxxxxxx
> > Subject: Re: [RFC PATCH 0/5] Utilizing VMX preemption for timer
> > virtualization
> > 
> > On Thu, May 19, 2016 at 06:44:58PM -0700, Yunhong Jiang wrote:
> > > The VMX-preemption timer is a feature on VMX, it counts down, from the
> > > value loaded by VM entry, in VMX nonroot operation. When the timer
> > > counts down to zero, it stops counting down and a VM exit occurs.
> > >
> > > The VMX preemption timer for tsc deadline timer virtualization. The
> > > VMX preemption timer is armed when the vCPU is running, and a VMExit
> > > will happen if the virtual TSC deadline timer expires.
> > >
> > > When the vCPU thread is scheduled out, the tsc deadline timer
> > > virtualization will be switched to use the current solution, i.e. use
> > > the timer for it. It's switched back to VMX preemption timer when the
> > > vCPU thread is scheduled int.
> > >
> > > This solution replace the complex OS's hrtimer system, and also the
> > > host timer interrupt handling cost, with a preemption_timer VMexit. It
> > > fits well for some NFV usage scenario, when the vCPU is bound to a
> > > pCPU and the pCPU is isolated, or some similar scenarioes.
> > >
> > > However, it possibly has impact if the vCPU thread is scheduled in/out
> > > very frequently, because it switches from/to the hrtimer emulation a
> > > lot. A module parameter is provided to turn it on or off.
> > >
> > > Signed-off-by: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>
> > 
> > Hi Yunhong Jiang,
> > 
> > This adds cost to the VM-exit and VM-entry paths (additional
> > instructions and i-cache pressure). Also it adds cost to
> > kvm_sched_out.
> 
> Hi, Marcelo,
>      Thanks for reply. As reply to Paolo's previous mail, I will change it so
> that there will be no extra cost to VM-exit/entry paths.
> 
>      Yes, it add costs to kvm_sched_out/in as stated in the commit
> message, so it's not good if the thread is scheduled in/out a lot.
> 
> > 
> > What is the benefit the switch from external interrupt to VMX preemption
> > timer brings?
> 
> The cost is the interrupt exit cost + HRtimer handler cost. I will get data on my next patch set.
> 
> Thanks
> --jyh

The data will be useful.

Paolo's argument about hrtimer_start/stop makes sense. 


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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