All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: 8bf00a529967dafbbb210b377c38a15834d1e979 - performance regression?
Date: Thu, 31 Oct 2013 09:48:08 +0200	[thread overview]
Message-ID: <20131031074808.GN4651@redhat.com> (raw)
In-Reply-To: <20131031002146.GA28569@redhat.com>

On Thu, Oct 31, 2013 at 02:21:46AM +0200, Michael S. Tsirkin wrote:
> commit 8bf00a529967dafbbb210b377c38a15834d1e979:
> "    KVM: VMX: add support for switching of PERF_GLOBAL_CTRL " was
> as far as I can tell supposed to bring about performance improvement
> on hardware that supports it?
No, it (and commits after it) supposed to fix a bug which it did.

> Instead it seems to make the typical case (not running guest
> under perf) a bit slower than it used to be.
> the cost of VMexit goes up by about 50 cycles
> on sandy bridge where the optimization in question
> actually is activated.
>
You seams to be confused. 8bf00a529967dafbbb210 adds support for special
PERF_GLOBAL_CTRL switching, but does not add code to switch anything,
so the commit itself is a nop. Next commit d7cd97964ba6d70c5
uses add_atomic_switch_msr()/clear_atomic_switch_msr()
to switch PERF_GLOBAL_CTRL, but it does not depend on
VM_(ENTRY|EXIT)_LOAD_IA32_PERF_GLOBAL_CTRL support which previous
patch added, if the support is not there the switching will use
another mechanism which is even slower. So MSR is switched no matter
if PERF_GLOBAL_CTRL is enabled or not.  If you saying that using
VM_(ENTRY|EXIT)_LOAD_IA32_PERF_GLOBAL_CTRL is slower than using generic
vmentry MSR switching then I pretty much doubt it since the only purpose
of special VM_(ENTRY|EXIT)_LOAD_IA32_PERF_GLOBAL_CTRL is to be faster
then general mechanism.

--
			Gleb.

  reply	other threads:[~2013-10-31  7:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-31  0:21 8bf00a529967dafbbb210b377c38a15834d1e979 - performance regression? Michael S. Tsirkin
2013-10-31  7:48 ` Gleb Natapov [this message]
2013-11-04 20:11   ` Michael S. Tsirkin
2013-11-04 20:13     ` Gleb Natapov
2013-11-04 20:33       ` Michael S. Tsirkin
2013-11-04 20:44         ` Gleb Natapov
2013-11-05 10:18           ` Michael S. Tsirkin
2013-11-05 10:22             ` Gleb Natapov
2013-11-05 11:20               ` Gleb Natapov
2013-11-05 16:36                 ` Michael S. Tsirkin
2013-11-05 16:40                   ` Gleb Natapov
2013-11-05 16:44                     ` Michael S. Tsirkin
2013-11-18 19:04                 ` Michael S. Tsirkin
2013-11-18 19:09                   ` Gleb Natapov
2013-11-18 19:37                     ` Michael S. Tsirkin
2013-11-04 19:30 ` Michael S. Tsirkin
2013-11-04 19:39   ` Gleb Natapov

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=20131031074808.GN4651@redhat.com \
    --to=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.