From: Peter Xu <peterx@redhat.com>
To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
Sean Christopherson <seanjc@google.com>,
peterx@redhat.com, Maxim Levitsky <mlevitsk@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: [PATCH v3 5/7] KVM: X86: MMU: Tune PTE_LIST_EXT to be bigger
Date: Fri, 30 Jul 2021 18:04:53 -0400 [thread overview]
Message-ID: <20210730220455.26054-6-peterx@redhat.com> (raw)
In-Reply-To: <20210730220455.26054-1-peterx@redhat.com>
Currently rmap array element only contains 3 entries. However for EPT=N there
could have a lot of guest pages that got tens of even hundreds of rmap entry.
A normal distribution of a 6G guest (even if idle) shows this with rmap count
statistics:
Rmap_Count: 0 1 2-3 4-7 8-15 16-31 32-63 64-127 128-255 256-511 512-1023
Level=4K: 3089171 49005 14016 1363 235 212 15 7 0 0 0
Level=2M: 5951 227 0 0 0 0 0 0 0 0 0
Level=1G: 32 0 0 0 0 0 0 0 0 0 0
If we do some more fork some pages will grow even larger rmap counts.
This patch makes PTE_LIST_EXT bigger so it'll be more efficient for the general
use case of EPT=N as we do list reference less and the loops over PTE_LIST_EXT
will be slightly more efficient; but still not too large so less waste when
array not full.
It should not affecting EPT=Y since EPT normally only has zero or one rmap
entry for each page, so no array is even allocated.
With a test case to fork 500 child and recycle them ("./rmap_fork 500" [1]),
this patch speeds up fork time of about 29%.
Before: 473.90 (+-5.93%)
After: 366.10 (+-4.94%)
[1] https://github.com/xzpeter/clibs/commit/825436f825453de2ea5aaee4bdb1c92281efe5b3
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/x86/kvm/mmu/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 16c99f771c9e..c0b452bb5dd9 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -137,8 +137,8 @@ module_param(dbg, bool, 0644);
#include <trace/events/kvm.h>
-/* make pte_list_desc fit well in cache line */
-#define PTE_LIST_EXT 3
+/* make pte_list_desc fit well in cache lines */
+#define PTE_LIST_EXT 15
struct pte_list_desc {
u64 *sptes[PTE_LIST_EXT];
--
2.31.1
next prev parent reply other threads:[~2021-07-30 22:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 22:04 [PATCH v3 0/7] KVM: X86: Some light optimizations on rmap logic Peter Xu
2021-07-30 22:04 ` [PATCH v3 1/7] KVM: Allow to have arch-specific per-vm debugfs files Peter Xu
2021-08-03 11:15 ` Greg KH
2021-08-03 19:25 ` Peter Xu
2021-07-30 22:04 ` [PATCH v3 2/7] KVM: X86: Introduce pte_list_count() helper Peter Xu
2021-07-30 22:04 ` [PATCH v3 3/7] KVM: X86: Introduce kvm_mmu_slot_lpages() helpers Peter Xu
2021-07-30 22:04 ` [PATCH v3 4/7] KVM: X86: Introduce mmu_rmaps_stat per-vm debugfs file Peter Xu
2021-08-02 15:25 ` Paolo Bonzini
2021-08-03 19:14 ` Peter Xu
2021-08-05 18:19 ` Sean Christopherson
2021-07-30 22:04 ` Peter Xu [this message]
2021-07-30 22:06 ` [PATCH v3 6/7] KVM: X86: Optimize pte_list_desc with per-array counter Peter Xu
2021-07-30 22:06 ` [PATCH v3 7/7] KVM: X86: Optimize zapping rmap Peter Xu
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=20210730220455.26054-6-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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.