From: Andrea Arcangeli <aarcange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Sean Christopherson <sean.j.christopherson@intel.com>
Subject: Re: [PATCH 12/14] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
Date: Tue, 15 Oct 2019 12:49:52 -0400 [thread overview]
Message-ID: <20191015164952.GE331@redhat.com> (raw)
In-Reply-To: <933ca564-973d-645e-fe9c-9afb64edba5b@redhat.com>
On Tue, Oct 15, 2019 at 10:28:39AM +0200, Paolo Bonzini wrote:
> If you're including EXIT_REASON_EPT_MISCONFIG (MMIO access) then you
> should include EXIT_REASON_IO_INSTRUCTION too. Depending on the devices
> that are in the guest, the doorbell register might be MMIO or PIO.
The fact outb/inb devices exists isn't the question here. The question
you should clarify is: which of the PIO devices is performance
critical as much as MMIO with virtio/vhost? I mean even on real
hardware those devices aren't performance critical. I didn't run into
PIO drivers with properly configured guests.
> So, the difference between my suggested list (which I admit is just
> based on conjecture, not benchmarking) is that you add
> EXIT_REASON_PAUSE_INSTRUCTION, EXIT_REASON_PENDING_INTERRUPT,
> EXIT_REASON_EXTERNAL_INTERRUPT, EXIT_REASON_HLT, EXIT_REASON_MSR_READ,
> EXIT_REASON_CPUID.
>
> Which of these make a difference for the hrtimer testcase? It's of
> course totally fine to use benchmarks to prove that my intuition was
> bad---but you must also use them to show why your intuition is right. :)
The hrtimer flood hits on this:
MSR_WRITE 338793 56.54% 5.51% 0.33us 34.44us 0.44us ( +- 0.20% )
PENDING_INTERRUPT 168431 28.11% 2.52% 0.36us 32.06us 0.40us ( +- 0.28% )
PREEMPTION_TIMER 91723 15.31% 1.32% 0.34us 30.51us 0.39us ( +- 0.41% )
EXTERNAL_INTERRUPT 234 0.04% 0.00% 0.25us 5.53us 0.43us ( +- 5.67% )
HLT 65 0.01% 90.64% 0.49us 319933.79us 37562.71us ( +- 21.68% )
MSR_READ 6 0.00% 0.00% 0.67us 1.96us 1.06us ( +- 17.97% )
EPT_MISCONFIG 6 0.00% 0.01% 3.09us 105.50us 26.76us ( +- 62.10% )
PENDING_INTERRUPT is the big missing thing in your list. It probably
accounts for the bulk of slowdown from your list. However I could
imagine other loads with higher external interrupt/hlt/rdmsr than the
hrtimer one so I didn't drop those. Other loads are hitting on a flood
of HLT and from host standpoint it's no a slow path. Not all OS have
the cpuidle haltpoll governor to mitigate the HLT frequency.
I'm pretty sure HLT/EXTERNAL_INTERRUPT/PENDING_INTERRUPT should be
included.
The least useful are PAUSE, CPUID and MSR_READ, we could considering
dropping some of those (in the short term cpuid helps for benchmarking
to more accurately measure the performance improvement of not hitting
the retpoline there). I simply could imagine some load hitting
frequently on those too so I didn't drop them.
I also wonder if VMCALL should be added, certain loads hit on fairly
frequent VMCALL, but none of the one I benchmarked.
next prev parent reply other threads:[~2019-10-15 16:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-28 17:23 [PATCH 00/14] KVM monolithic v2 Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 01/14] KVM: monolithic: x86: remove kvm.ko Andrea Arcangeli
2019-10-15 1:31 ` Sean Christopherson
2019-10-15 3:18 ` Sean Christopherson
2019-10-15 8:32 ` Paolo Bonzini
2019-09-28 17:23 ` [PATCH 02/14] KVM: monolithic: x86: disable linking vmx and svm at the same time into the kernel Andrea Arcangeli
2019-10-15 3:16 ` Sean Christopherson
2019-10-15 8:21 ` Paolo Bonzini
2019-10-15 15:23 ` Sean Christopherson
2019-09-28 17:23 ` [PATCH 03/14] KVM: monolithic: x86: convert the kvm_x86_ops and kvm_pmu_ops methods to external functions Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 04/14] KVM: monolithic: x86: handle the request_immediate_exit variation Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 05/14] KVM: monolithic: add more section prefixes in the KVM common code Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 06/14] KVM: monolithic: x86: remove __exit section prefix from machine_unsetup Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 07/14] KVM: monolithic: x86: remove __init section prefix from kvm_x86_cpu_has_kvm_support Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 08/14] KVM: monolithic: x86: remove exports Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 09/14] KVM: monolithic: remove exports from KVM common code Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 10/14] KVM: monolithic: x86: drop the kvm_pmu_ops structure Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 11/14] KVM: x86: optimize more exit handlers in vmx.c Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 12/14] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers Andrea Arcangeli
2019-10-15 8:28 ` Paolo Bonzini
2019-10-15 16:49 ` Andrea Arcangeli [this message]
2019-10-15 19:46 ` Paolo Bonzini
2019-10-15 20:35 ` Andrea Arcangeli
2019-10-15 22:22 ` Paolo Bonzini
2019-10-15 23:42 ` Andrea Arcangeli
2019-10-16 7:07 ` Paolo Bonzini
2019-10-16 16:50 ` Andrea Arcangeli
2019-10-16 17:01 ` Paolo Bonzini
2019-09-28 17:23 ` [PATCH 13/14] KVM: retpolines: x86: eliminate retpoline from svm.c " Andrea Arcangeli
2019-09-28 17:23 ` [PATCH 14/14] x86: retpolines: eliminate retpoline from msr event handlers Andrea Arcangeli
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=20191015164952.GE331@redhat.com \
--to=aarcange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@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.