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

[yunhong jiang <yunhong.jiang@linux.intel.com>]

On Fri, 20 May 2016 22:27:08 +0000
"Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:

> 
> 
> > -----Original Message-----
> > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> > On Behalf Of Paolo Bonzini
> > Sent: Friday, May 20, 2016 1:49 PM
> > To: Marcelo Tosatti <mtosatti@redhat.com>
> > Cc: Yunhong Jiang <yunhong.jiang@linux.intel.com>;
> > kvm@vger.kernel.org; rkrcmar@redhat.com
> > 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@intel.com>
> > >
> > > 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.
> > 
> > For now my review limited itself to making the code nicer without
> > touching the overall design too much.
> > 
> > I'm confident that we can reduce it to a dozen instructions on
> > vmentry
> 
> If we set the preemption timer on the first vm-entry, and then there
> is a vm-exit because of another reason, on the second vm-entry, do we
> need update the VMX_PREEMPTION_TIMER_VALUE value? If no, then we don't
> need anything special on the vmentry. We simply set the VMCS in
> sched_in or when guest program the timer.

Please just ignore this, brain dead at that time. We have to setup the
VMX_PREEMPTION_TIMER_VALUE every time.

--jyh

> 
> Thanks
> --jyh
> 
> > and only pay the cost of hrtimer_start on failed HLT polls (enabling
> > the hrtimer only before going to sleep).  Assuming that device
> > interrupts are delivered while the guest is running or during a
> > successful HLT polls, that would be very rare.
> > 
> > > What is the benefit the switch from external interrupt to VMX
> > > preemption timer brings?
> > 
> > hrtimer_start/hrtimer_cancel do show up in profiles for dynticks
> > guests. Since they touch a red-black tree, it shouldn't be hard to
> > outperform them.
> > 
> > Paolo
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html