From: Sean Christopherson <seanjc@google.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 0/5] KVM: Put struct kvm_vcpu on a diet
Date: Fri, 17 Feb 2023 08:35:36 -0800 [thread overview]
Message-ID: <Y++s2LvnBxydxhVM@google.com> (raw)
In-Reply-To: <2c2f77a3-1d77-0d88-991a-60dcdc370ea8@grsecurity.net>
On Fri, Feb 17, 2023, Mathias Krause wrote:
> On 16.02.23 18:32, Sean Christopherson wrote:
> > I'm not necessarily opposed to such aggressive optimization, but the ROI is likely
> > very, very low. For optimized workloads, there simply aren't very many VM-Exits,
> > e.g. the majority of exits on a modern CPU are due to timer ticks. And even those
> > will hopefully be eliminiated in the not-too-distant future, e.g. by having hardware
> > virtualize the TSC deadline timer, and by moving to a vCPU scheduling scheme that
> > allows for a tickless host.
>
> Well, for guests running grsecurity kernels, there's also the CR0.WP
> toggling triggering VMEXITs, which happens a lot! -- at least until
> something along the lines of [1] gets merged *hint ;)*
Ha! It's high on my todo list for 6.4, catching up on other stuff at the moment.
That series is also _exactly_ why the ROI for aggressive cache line optimization
is low. The better long term answer is almost always to avoid the VM-Exit in the
first place, or failing that, to handle the exit in a fastpath. Sometimes it takes
a few years, e.g. to get necessary hardware support, but x86 virtualization is fast
approaching the point where anything remotely performance critical is handled entirely
within the guest.
prev parent reply other threads:[~2023-02-17 16:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 16:33 [PATCH 0/5] KVM: Put struct kvm_vcpu on a diet Mathias Krause
2023-02-13 16:33 ` [PATCH 1/5] KVM: x86: Shrink struct kvm_pmu Mathias Krause
2023-02-13 16:33 ` [PATCH 2/5] KVM: x86: Shrink struct kvm_queued_exception Mathias Krause
2023-02-18 14:55 ` Tom Lendacky
2023-02-13 16:33 ` [PATCH 3/5] KVM: Shrink struct kvm_mmu_memory_cache Mathias Krause
2023-02-13 17:08 ` Sean Christopherson
2023-02-14 12:20 ` Mathias Krause
2023-02-13 16:33 ` [PATCH 4/5] KVM: x86: Shrink struct kvm_vcpu_arch Mathias Krause
2023-02-13 16:33 ` [PATCH 5/5] KVM: Shrink struct kvm_vcpu Mathias Krause
2023-02-13 17:05 ` [PATCH 0/5] KVM: Put struct kvm_vcpu on a diet Sean Christopherson
2023-02-14 12:19 ` Mathias Krause
2023-02-16 17:32 ` Sean Christopherson
2023-02-17 16:07 ` Mathias Krause
2023-02-17 16:35 ` Sean Christopherson [this message]
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=Y++s2LvnBxydxhVM@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minipli@grsecurity.net \
--cc=pbonzini@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 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).