From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Sergey Senozhatsky <senozhatsky@google.com>,
Ben Gardon <bgardon@google.com>
Subject: Re: [PATCH] KVM: x86/mmu: Complete prefetch for trailing SPTEs for direct, legacy MMU
Date: Thu, 19 Aug 2021 13:15:23 +0900 [thread overview]
Message-ID: <YR3a21l6TC/gmw3/@google.com> (raw)
In-Reply-To: <20210818235615.2047588-1-seanjc@google.com>
[..]
> Make a final call to direct_pte_prefetch_many() if there are "trailing"
> SPTEs to prefetch, i.e. SPTEs for GFNs following the faulting GFN. The
> call to direct_pte_prefetch_many() in the loop only handles the case
> where there are !PRESENT SPTEs preceding a PRESENT SPTE.
>
> E.g. if the faulting GFN is a multiple of 8 (the prefetch size) and all
> SPTEs for the following GFNs are !PRESENT, the loop will terminate with
> "start = sptep+1" and not prefetch any SPTEs.
>
> Prefetching trailing SPTEs as intended can drastically reduce the number
> of guest page faults, e.g. accessing the first byte of every 4kb page in
> a 6gb chunk of virtual memory, in a VM with 8gb of preallocated memory,
> the number of pf_fixed events observed in L0 drops from ~1.75M to <0.27M.
>
> Note, this only affects memory that is backed by 4kb pages as KVM doesn't
> prefetch when installing hugepages. Shadow paging prefetching is not
> affected as it does not batch the prefetches due to the need to process
> the corresponding guest PTE. The TDP MMU is not affected because it
> doesn't have prefetching, yet...
Tested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
I ran some tests.
- VM Boot up
From
EPT_VIOLATION 1192184 75.18% 4.40% 0.77us 18020.01us 4.32us ( +- 1.71% )
to
EPT_VIOLATION 947460 69.92% 4.64% 0.69us 34902.15us 5.06us ( +- 1.64% )
- Running test app (in VM)
From
EPT_VIOLATION 6550167 71.05% 11.76% 0.77us 32562.18us 3.51us ( +- 0.36% )
to
EPT_VIOLATION 5489904 68.32% 11.29% 0.71us 16564.19us 3.92us ( +- 0.29% )
next prev parent reply other threads:[~2021-08-19 4:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 23:56 [PATCH] KVM: x86/mmu: Complete prefetch for trailing SPTEs for direct, legacy MMU Sean Christopherson
2021-08-19 4:15 ` Sergey Senozhatsky [this message]
2021-08-25 22:49 ` Lai Jiangshan
2021-08-26 21:35 ` Ben Gardon
2021-09-23 16:27 ` Paolo Bonzini
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=YR3a21l6TC/gmw3/@google.com \
--to=senozhatsky@chromium.org \
--cc=bgardon@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.com \
--cc=senozhatsky@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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.