From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: Konstantin Khorenko <khorenko@virtuozzo.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Denis V. Lunev" <den@virtuozzo.com>
Subject: Re: [PATCH 0/1] KVM: x86/vPMU: Speed up vmexit for AMD Zen 4 CPUs
Date: Thu, 9 Nov 2023 15:42:35 -0800 [thread overview]
Message-ID: <ZU1ua1mHDZFTmkHX@google.com> (raw)
In-Reply-To: <CALMp9eQGqqo66fQGwFJMc3y+9XdUrL7ageE8kvoAOV6NJGfJpw@mail.gmail.com>
On Thu, Nov 09, 2023, Jim Mattson wrote:
> On Thu, Nov 9, 2023 at 10:24 AM Konstantin Khorenko
> <khorenko@virtuozzo.com> wrote:
> >
> > We have detected significant performance drop of our atomic test which
> > checks the rate of CPUID instructions rate inside an L1 VM on an AMD
> > node.
> >
> > Investigation led to 2 mainstream patches which have introduced extra
> > events accounting:
> >
> > 018d70ffcfec ("KVM: x86: Update vPMCs when retiring branch instructions")
> > 9cd803d496e7 ("KVM: x86: Update vPMCs when retiring instructions")
> >
> > And on an AMD Zen 3 CPU that resulted in immediate 43% drop in the CPUID
> > rate.
> >
> > Checking latest mainsteam kernel the performance difference is much less
> > but still quite noticeable: 13.4% and shows up on AMD CPUs only.
> >
> > Looks like iteration over all PMCs in kvm_pmu_trigger_event() is cheap
> > on Intel and expensive on AMD CPUs.
> >
> > So the idea behind this patch is to skip iterations over PMCs at all in
> > case PMU is disabled for a VM completely or PMU is enabled for a VM, but
> > there are no active PMCs at all.
>
> A better solution may be to maintain two bitmaps of general purpose
> counters that need to be incremented, one for instructions retired and
> one for branch instructions retired. Set or clear these bits whenever
> the PerfEvtSelN MSRs are written. I think I would keep the PGC bits
> separate, on those microarchitectures that support PGC. Then,
> kvm_pmu_trigger_event() need only consult the appropriate bitmap (or
> the logical and of that bitmap with PGC). In most cases, the value
> will be zero, and the function can simply return.
>
> This would work even for AMD microarchitectures that don't support PGC.
Yeah. There are multiple lower-hanging fruits to be picked though, most of which
won't conflict with using dedicated per-event bitmaps, or at worst are trivial
to resolve.
1. Don't call into perf to get the eventsel (which generates an indirect call)
on every invocation, let alone every iteration.
2. Avoid getting the CPL when it's irrelevant.
3. Check the eventsel before querying the event filter.
4. Mask out PMCs that aren't globally enabled from the get-go (masking out
PMCs based on eventsel would essentially be the same as per-event bitmaps).
I'm definitely not opposed to per-event bitmaps, but it'd be nice to avoid them,
e.g. if we can eke out 99% of the performance just by doing a few obvious
optimizations.
This is the end result of what I'm testing and will (hopefully) post shortly:
static inline bool pmc_is_eventsel_match(struct kvm_pmc *pmc, u64 eventsel)
{
return !((pmc->eventsel ^ eventsel) & AMD64_RAW_EVENT_MASK_NB);
}
static inline bool cpl_is_matched(struct kvm_pmc *pmc)
{
bool select_os, select_user;
u64 config;
if (pmc_is_gp(pmc)) {
config = pmc->eventsel;
select_os = config & ARCH_PERFMON_EVENTSEL_OS;
select_user = config & ARCH_PERFMON_EVENTSEL_USR;
} else {
config = fixed_ctrl_field(pmc_to_pmu(pmc)->fixed_ctr_ctrl,
pmc->idx - KVM_FIXED_PMC_BASE_IDX);
select_os = config & 0x1;
select_user = config & 0x2;
}
/*
* Skip the CPL lookup, which isn't free on Intel, if the result will
* be the same regardless of the CPL.
*/
if (select_os == select_user)
return select_os;
return (static_call(kvm_x86_get_cpl)(pmc->vcpu) == 0) ? select_os : select_user;
}
void kvm_pmu_trigger_event(struct kvm_vcpu *vcpu, u64 eventsel)
{
DECLARE_BITMAP(bitmap, X86_PMC_IDX_MAX);
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc;
int i;
BUILD_BUG_ON(sizeof(pmu->global_ctrl) * BITS_PER_BYTE != X86_PMC_IDX_MAX);
if (!kvm_pmu_has_perf_global_ctrl(pmu))
bitmap_copy(bitmap, pmu->all_valid_pmc_idx, X86_PMC_IDX_MAX);
else if (!bitmap_and(bitmap, pmu->all_valid_pmc_idx,
(unsigned long *)&pmu->global_ctrl, X86_PMC_IDX_MAX))
return;
kvm_for_each_pmc(pmu, pmc, i, bitmap) {
/* Ignore checks for edge detect, pin control, invert and CMASK bits */
if (!pmc_is_eventsel_match(pmc, eventsel) ||
!pmc_event_is_allowed(pmc) || !cpl_is_matched(pmc))
continue;
kvm_pmu_incr_counter(pmc);
}
}
next prev parent reply other threads:[~2023-11-09 23:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 18:06 [PATCH 0/1] KVM: x86/vPMU: Speed up vmexit for AMD Zen 4 CPUs Konstantin Khorenko
2023-11-09 18:06 ` [PATCH 1/1] KVM: x86/vPMU: Check PMU is enabled for vCPU before searching for PMC Konstantin Khorenko
2023-11-09 20:09 ` Sean Christopherson
2023-11-09 20:13 ` Jim Mattson
2023-11-09 23:05 ` Sean Christopherson
2023-11-09 18:18 ` KVM: x86/vPMU/AMD: Can we detect PMU is off for a VM? Konstantin Khorenko
2023-11-09 22:52 ` Jim Mattson
2023-11-09 23:46 ` Denis V. Lunev
2023-11-10 0:01 ` Dongli Zhang
2023-11-13 9:31 ` Denis V. Lunev
2023-11-13 14:14 ` Dongli Zhang
2023-11-13 14:42 ` Denis V. Lunev
2023-11-13 16:17 ` Dongli Zhang
2023-11-13 16:33 ` Denis V. Lunev
2023-11-10 0:02 ` Jim Mattson
2023-11-09 22:44 ` [PATCH 0/1] KVM: x86/vPMU: Speed up vmexit for AMD Zen 4 CPUs Jim Mattson
2023-11-09 23:42 ` Sean Christopherson [this message]
2023-11-10 0:17 ` Jim Mattson
2023-11-10 0:52 ` Sean Christopherson
2023-11-10 1:14 ` Sean Christopherson
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=ZU1ua1mHDZFTmkHX@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=den@virtuozzo.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=khorenko@virtuozzo.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox