From: Sean Christopherson <seanjc@google.com>
To: Makarand Sonare <makarandsonare@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, pshier@google.com, jmattson@google.com,
Ben Gardon <bgardon@google.com>
Subject: Re: [RESEND PATCH ] KVM: VMX: Enable/disable PML when dirty logging gets enabled/disabled
Date: Wed, 10 Feb 2021 18:07:06 -0800 [thread overview]
Message-ID: <YCSRSiSNErkC6+9R@google.com> (raw)
In-Reply-To: <20210210212308.2219465-1-makarandsonare@google.com>
On Wed, Feb 10, 2021, Makarand Sonare wrote:
> Currently, if enable_pml=1 PML remains enabled for the entire lifetime
> of the VM irrespective of whether dirty logging is enable or disabled.
> When dirty logging is disabled, all the pages of the VM are manually
> marked dirty, so that PML is effectively non-operational. Clearing
> the dirty bits is an expensive operation which can cause severe MMU
> lock contention in a performance sensitive path when dirty logging
> is disabled after a failed or canceled live migration. Also, this
> would break if some other code path clears the dirty bits in which
> case, PML will actually start logging dirty pages even when dirty
> logging is disabled incurring unnecessary vmexits when the PML buffer
> becomes full. In order to avoid this extra overhead, we should
> enable or disable PML in VMCS when dirty logging gets enabled
> or disabled instead of keeping it always enabled.
Breaking this up into a few paragraphs would be helpful.
> Tested:
> kvm-unit-tests
> dirty_log_test
> dirty_log_perf_test
Eh, I get that we like these for internal tracking, but for upstream there's an
assumption that you did your due diligence. If there's something noteworthy
about your testing (or lack thereof), throw it in the cover letter or in the
part that's not recorded in the final commit.
> Signed-off-by: Makarand Sonare <makarandsonare@google.com>
> Reviewed-by: Ben Gardon <bgardon@google.com>
> ---
...
> @@ -7517,9 +7531,39 @@ static void vmx_slot_enable_log_dirty(struct kvm *kvm,
> static void vmx_slot_disable_log_dirty(struct kvm *kvm,
> struct kvm_memory_slot *slot)
> {
> + /*
> + * Check all slots and disable PML if dirty logging
> + * is being disabled for the last slot
> + *
> + */
> + if (enable_pml &&
> + kvm->dirty_logging_enable_count == 0 &&
> + kvm->arch.pml_enabled) {
> + kvm->arch.pml_enabled = false;
> + kvm_make_all_cpus_request(kvm,
> + KVM_REQ_UPDATE_VCPU_DIRTY_LOGGING_STATE);
> + }
> +
> kvm_mmu_slot_set_dirty(kvm, slot);
The justification for dynamically toggling PML is that it means KVM can skip
setting all the dirty bits when logging is disabled, but that code is still here.
Is there a follow-up planned to reap the reward?
> }
next prev parent reply other threads:[~2021-02-11 2:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 21:23 [RESEND PATCH ] KVM: VMX: Enable/disable PML when dirty logging gets enabled/disabled Makarand Sonare
2021-02-11 0:55 ` Sean Christopherson
2021-02-11 9:04 ` Paolo Bonzini
2021-02-11 18:20 ` Sean Christopherson
2021-02-11 2:07 ` Sean Christopherson [this message]
2021-02-11 8:58 ` Paolo Bonzini
2021-02-11 9:04 ` Paolo Bonzini
2021-02-11 15:53 ` Sean Christopherson
2021-02-12 18:12 ` Sean Christopherson
2021-02-12 19:14 ` Makarand Sonare
2021-02-12 21:18 ` Sean Christopherson
2021-02-12 22:13 ` 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=YCSRSiSNErkC6+9R@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=makarandsonare@google.com \
--cc=pbonzini@redhat.com \
--cc=pshier@google.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