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: Igor Mammedov <imammedo@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 7/7] target/i386: Enable kvm_pv_unhalt by default
Date: Mon, 9 Oct 2017 16:40:55 +0200	[thread overview]
Message-ID: <0484ea3f-4ba7-4b93-e976-098c5717166e@redhat.com> (raw)
In-Reply-To: <20171006215244.27104-8-ehabkost@redhat.com>

On 06/10/2017 23:52, Eduardo Habkost wrote:
>   Commit f010bc643a (target-i386: add feature kvm_pv_unhalt) introduced the
>   kvm_pv_unhalt feature but didn't enable it by default.
> 
>   Without kvm_pv_unhalt we see a measurable degradation in scheduling
>   performance, so enabling it by default does make sense IMHO. This patch
>   just flips it to default to on by default.
> 
>     [With kvm_pv_unhalt disabled]
>     $ perf bench sched messaging -l 10000
>       Total time: 8.573 [sec]
> 
>     [With kvm_pv_unhalt enabled]
>     $ perf bench sched messaging -l 10000
>       Total time: 4.416 [sec]

I cannot reproduce this:

Host CPU model: Haswell-EP (Xeon E5-2697 v3 @ 2.60 GHz)
Host physical CPUs: 56 (2 sockets 14 cores/sockets, 2 thread/core)
Host Linux kernel: 4.14 (more or less :))
Host memory: 64 GB
Guest Linux kernel: 4.10.13

QEMU command line:

/usr/libexec/qemu-kvm -cpu host,+kvm_pv_unhalt -M q35 \
   -m XXX -smp YYY \
   /path/to/vm.qcow2

(XXX = MiB of guest memory, YYY = number of guest processors)

"perf bench sched messaging -l 50000" has the following result for me:

Guest vCPUs    Guest memory     without PV unhalt      with PV unhalt
1*96           32 GB            24.6 s                 24.2 s
2*96           24 GB            47.9 s (both VMs)      46.8 s (both VMs)
2*48           16 GB            50.4 s (both VMs)      49.3 s (both VMs)
4*24           12 GB            82.1 - 89.0 s          82.3 - 88.8 s
4*4            12 GB            87.2 - 91.3 s          90.3 - 94.9 s

All but the first line are running the benchmark in multiple guests,
concurrently.  The improvement seems to be about 2-3% for guests larger
than 1 NUMA node, and zero or negative for smaller guests (especially as
the host is no longer overcommitted).

The difference for large NUMA guests is small but I ran the benchmark
multiple times and it is statistically significant---but not as large as
what Alex reported.

Paolo

  reply	other threads:[~2017-10-09 14:41 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 [this message]
2017-10-09 14:43     ` Alexander Graf
2017-10-09 13:39 ` [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable " Paolo Bonzini
2017-10-09 15:15   ` 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=0484ea3f-4ba7-4b93-e976-098c5717166e@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agraf@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@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.