public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: "Jiang, Yunhong" <yunhong.jiang@intel.com>
Cc: Yunhong Jiang <yunhong.jiang@linux.intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [RFC PATCH 0/5] Utilizing VMX preemption for timer virtualization
Date: Fri, 20 May 2016 21:45:22 -0300	[thread overview]
Message-ID: <20160521004522.GA7314@amt.cnet> (raw)
In-Reply-To: <DDCAE26804250545B9934A2056554AA020F838EC@ORSMSX112.amr.corp.intel.com>

GOn Fri, May 20, 2016 at 10:18:47PM +0000, Jiang, Yunhong wrote:
> 
> 
> > -----Original Message-----
> > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
> > Behalf Of Marcelo Tosatti
> > Sent: Friday, May 20, 2016 11:19 AM
> > To: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> > Cc: kvm@vger.kernel.org; rkrcmar@redhat.com; pbonzini@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.
> 
> 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. 



      reply	other threads:[~2016-05-22 22:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20  1:44 [RFC PATCH 0/5] Utilizing VMX preemption for timer virtualization Yunhong Jiang
2016-05-20  1:44 ` [RFC PATCH 1/5] Add the kvm sched_out hook Yunhong Jiang
2016-05-20  1:45 ` [RFC PATCH 2/5] Utilize the vmx preemption timer Yunhong Jiang
2016-05-20  9:45   ` Paolo Bonzini
2016-05-20  1:45 ` [RFC PATCH 3/5] Separate the start_sw_tscdeadline Yunhong Jiang
2016-05-20 10:16   ` Paolo Bonzini
2016-05-20  1:45 ` [RFC PATCH 4/5] Utilize the vmx preemption timer for tsc deadline timer Yunhong Jiang
2016-05-20 10:34   ` Paolo Bonzini
2016-05-20 22:06     ` Jiang, Yunhong
2016-05-21 12:38       ` Paolo Bonzini
2016-05-22  0:21       ` Wanpeng Li
2016-05-23 22:58         ` yunhong jiang
2016-05-24  0:53           ` Wanpeng Li
2016-05-24  0:55             ` yunhong jiang
2016-05-24  1:16               ` Wanpeng Li
2016-05-24  1:20                 ` yunhong jiang
2016-05-24  1:32                   ` Wanpeng Li
2016-05-20  1:45 ` [RFC PATCH 5/5] Adding trace for the hwemul_timer Yunhong Jiang
2016-05-20 10:28   ` Paolo Bonzini
2016-05-20  6:03 ` [RFC PATCH 0/5] Utilizing VMX preemption for timer virtualization Jan Kiszka
2016-05-20  9:41   ` Paolo Bonzini
2016-05-20 21:50   ` Jiang, Yunhong
2016-05-20 18:18 ` Marcelo Tosatti
2016-05-20 18:21   ` Marcelo Tosatti
2016-05-20 20:49   ` Paolo Bonzini
2016-05-20 22:27     ` Jiang, Yunhong
2016-05-20 23:53       ` yunhong jiang
2016-05-20 22:18   ` Jiang, Yunhong
2016-05-21  0:45     ` Marcelo Tosatti [this message]

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=20160521004522.GA7314@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=yunhong.jiang@intel.com \
    --cc=yunhong.jiang@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox