On Fri, 20 May 2016 22:27:08 +0000 "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote: > > > > -----Original Message----- > > From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] > > On Behalf Of Paolo Bonzini > > Sent: Friday, May 20, 2016 1:49 PM > > To: Marcelo Tosatti <mtosatti@xxxxxxxxxx> > > Cc: Yunhong Jiang <yunhong.jiang@xxxxxxxxxxxxxxx>; > > kvm@xxxxxxxxxxxxxxx; rkrcmar@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. > > > > 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@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
