All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Waiman Long <longman@redhat.com>,
	Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable kvm_pv_unhalt by default
Date: Mon, 9 Oct 2017 15:39:26 +0200	[thread overview]
Message-ID: <765f7133-0ccc-2239-d49b-55d8b2a24cc7@redhat.com> (raw)
In-Reply-To: <20171006215244.27104-1-ehabkost@redhat.com>

On 06/10/2017 23:52, Eduardo Habkost wrote:
> This series enables kvm_pv_unhalt by default on pc-*-2.11 and
> newer.
> 
> To do that, I first reworked the existing
> x86_cpu_change_kvm_default() logic to use compat_props instead,
> so we don't need to make the chain of pc_compat_*() functions
> grow.

I've discussed PV spinlocks with some folks at Microsoft for a few weeks
now, and I'm not 100% sure about enabling kvm_pv_unhalt by default.
It's probably a good idea overall, but it does come with some caveats.

The problem is that there were two different implementations of fair
spinlocks in Linux, ticket spinlocks and queued spinlocks.  When
kvm_pv_unhalt is disabled, ticket spinlocks sucked badly indeed; queued
spinlocks however simply revert to unfair spinlocks, which loses the
fairness but has the best performance.  See virt_spin_lock in
arch/x86/include/asm/qspinlock.h.

Now, fair spinlocks are only really needed for large NUMA machines.
With a single NUMA node, for example, test-and-set spinlocks work well
enough; there's not _much_ need for fairness in practice, and the
paravirtualization does introduce some overhead.

Therefore, the best performance would be achieved with kvm_pv_unhalt
disabled on small VMs, and enabled on large VMs spanning multiple host
NUMA nodes.

Waiman, Davidlohr, do you have an opinion on this as well?

Paolo

  parent reply	other threads:[~2017-10-09 13:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 21:52 [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable kvm_pv_unhalt by default Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 1/7] qemu-doc: Document minimum kernel version for KVM in x86_64 Eduardo Habkost
2017-10-09 13:40   ` Paolo Bonzini
2017-10-10 15:33     ` Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 2/7] target/i386: x86_cpu_expand_feature() helper Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 3/7] target/i386: Use global variables to control KVM defaults Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 4/7] kvm: Define KVM_FEAT_* even if CONFIG_KVM is not defined Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 5/7] target/i386: Handle kvm_auto_* compat in x86_cpu_expand_features() Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 6/7] pc: Use compat_props to control KVM defaults compatibility Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 7/7] target/i386: Enable kvm_pv_unhalt by default Eduardo Habkost
2017-10-09 14:40   ` Paolo Bonzini
2017-10-09 14:43     ` Alexander Graf
2017-10-09 13:39 ` Paolo Bonzini [this message]
2017-10-09 15:15   ` [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable " Waiman Long
2017-10-09 15:47     ` Paolo Bonzini
2017-10-10 15:50       ` Eduardo Habkost
2017-10-10 18:07         ` Waiman Long
2017-10-10 19:41           ` Eduardo Habkost
2017-10-11 20:19             ` Waiman Long
2017-10-13 19:01               ` Eduardo Habkost
2017-10-13 20:58                 ` Waiman Long
2017-10-13 23:56                   ` Eduardo Habkost
2017-11-07 11:21                     ` [Qemu-devel] [libvirt] " Paolo Bonzini
2017-11-08 20:07                       ` Eduardo Habkost

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=765f7133-0ccc-2239-d49b-55d8b2a24cc7@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=dave@stgolabs.net \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=longman@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.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 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.