kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jintack Lim <incredible.tack@gmail.com>
Cc: KVM General <kvm@vger.kernel.org>, Jintack Lim <jintack@cs.columbia.edu>
Subject: Re: Why are we using preemption timer on x86?
Date: Wed, 7 Aug 2019 16:54:23 -0700	[thread overview]
Message-ID: <20190807235423.GD16491@linux.intel.com> (raw)
In-Reply-To: <CAHyh4xhDZdr0gOJCrSBB5rXYXw7Kpxsw_Oe=tSHMCgi_2G3ouQ@mail.gmail.com>

On Wed, Aug 07, 2019 at 02:52:19PM -0700, Jintack Lim wrote:
> Hi,
> 
> I'm just wondering what's the reason why we use the preemption timer
> instead of emulating VM's timer using hrtimer in software? Is there
> anything the the preemption timer can do that can't be done with
> hrtimer?
> 
> I guess the x86 architecture provides the preemption timer for *some*
> reason, but I'm not sure what they are.

Assuming you're referring to Intel/VMX's preemption timer, programming
the preemption timer and servicing its VM-Exits both have lower overhead
than going through hrtimer.

commit ce7a058a2117f0bca2f42f2870a97bfa9aa8e099
Author: Yunhong Jiang <yunhong.jiang@gmail.com>
Date:   Mon Jun 13 14:20:01 2016 -0700

    KVM: x86: support using the vmx preemption timer for tsc deadline timer

    The VMX preemption timer can be used to virtualize the TSC deadline timer.
    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 blocked because of HLT, KVM will switch to use
    an hrtimer, and then go back to the VMX preemption timer when the vCPU
    thread is unblocked.

    This solution avoids the complex OS's hrtimer system, and the host
    timer interrupt handling cost, replacing them with a little math
    (for guest->host TSC and host TSC->preemption timer conversion)
    and a cheaper VMexit.  This benefits latency for isolated pCPUs.

    [A word about performance... Yunhong reported a 30% reduction in average
     latency from cyclictest.  I made a similar test with tscdeadline_latency
     from kvm-unit-tests, and measured

     - ~20 clock cycles loss (out of ~3200, so less than 1% but still
       statistically significant) in the worst case where the test halts
       just after programming the TSC deadline timer

     - ~800 clock cycles gain (25% reduction in latency) in the best case
       where the test busy waits.

     I removed the VMX bits from Yunhong's patch, to concentrate them in the
     next patch - Paolo]

    Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

  reply	other threads:[~2019-08-07 23:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 21:52 Why are we using preemption timer on x86? Jintack Lim
2019-08-07 23:54 ` Sean Christopherson [this message]
2019-08-08  7:28   ` Jintack Lim

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=20190807235423.GD16491@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=incredible.tack@gmail.com \
    --cc=jintack@cs.columbia.edu \
    --cc=kvm@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).