All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: David Matlack <dmatlack@google.com>
Cc: maobibo <maobibo@loongson.cn>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,  Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	 Tianrui Zhao <zhaotianrui@loongson.cn>,
	Huacai Chen <chenhuacai@kernel.org>,
	 Michael Ellerman <mpe@ellerman.id.au>,
	Anup Patel <anup@brainfault.org>,
	 Christian Borntraeger <borntraeger@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	 Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: Re: [PATCH v2] KVM: Aggressively drop and reacquire mmu_lock during CLEAR_DIRTY_LOG
Date: Thu, 4 Apr 2024 11:17:24 -0700	[thread overview]
Message-ID: <Zg7utCRWGDvxdQ6a@google.com> (raw)
In-Reply-To: <CALzav=cF+tq-snKbdP76FpodUdd7Fhu9Pf3jTK5c5=vb-MY9cQ@mail.gmail.com>

On Thu, Apr 04, 2024, David Matlack wrote:
> > I don't love the idea of adding more arch specific MMU behavior (going the wrong
> > direction), but it doesn't seem like an unreasonable approach in this case.
> 
> I wonder if this is being overly cautious.

Probably.  "Lazy" is another word for it ;-)

> I would expect only more benefit on architectures that more aggressively take
> the mmu_lock on vCPU threads during faults. The more lock acquisition on vCPU
> threads, the more this patch will help reduce vCPU starvation during
> CLEAR_DIRTY_LOG.
> 
> Hm, perhaps testing with ept=N (which will use the write-lock for even
> dirty logging faults) would be a way to increase confidence in the
> effect on other architectures?

Turning off the TDP MMU would be more representative, just manually disable the
fast-path, e.g.

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 992e651540e8..532c24911f39 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3371,7 +3371,7 @@ static bool page_fault_can_be_fast(struct kvm_page_fault *fault)
         * Note, instruction fetches and writes are mutually exclusive, ignore
         * the "exec" flag.
         */
-       return fault->write;
+       return false;//fault->write;
 }
 
 /*


  reply	other threads:[~2024-04-04 18:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 21:36 [PATCH v2] KVM: Aggressively drop and reacquire mmu_lock during CLEAR_DIRTY_LOG David Matlack
2024-04-03  1:50 ` maobibo
2024-04-03 17:20   ` Sean Christopherson
2024-04-04 16:29   ` David Matlack
2024-04-04 17:10     ` Sean Christopherson
2024-04-04 18:12       ` David Matlack
2024-04-04 18:17         ` Sean Christopherson [this message]
2024-04-12 16:14           ` David Matlack
2024-04-15 17:20             ` David Matlack
2024-04-15 20:00               ` Sean Christopherson
2024-04-18 18:50                 ` David Matlack
2024-04-18 19:39                   ` Sean Christopherson
2024-04-07  2:25       ` maobibo
2024-04-12 16:12         ` David Matlack
2024-04-15  1:21           ` maobibo
2024-04-07  1:36     ` maobibo

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=Zg7utCRWGDvxdQ6a@google.com \
    --to=seanjc@google.com \
    --cc=anup@brainfault.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=chenhuacai@kernel.org \
    --cc=dmatlack@google.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=maobibo@loongson.cn \
    --cc=maz@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=zhaotianrui@loongson.cn \
    /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.