From: David Hildenbrand <david@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: rkrcmar@redhat.com, Vitaly Kuznetsov <vkuznets@redhat.com>,
Junaid Shahid <junaids@google.com>,
Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [PATCH] KVM: try __get_user_pages_fast even if not in atomic context
Date: Mon, 30 Jul 2018 10:40:26 +0200 [thread overview]
Message-ID: <65bee5ae-6bd8-38ff-d966-b1cf40d75d44@redhat.com> (raw)
In-Reply-To: <1532706407-11380-1-git-send-email-pbonzini@redhat.com>
On 27.07.2018 17:46, Paolo Bonzini wrote:
> We are currently cutting hva_to_pfn_fast short if we do not want an
> immediate exit, which is represented by !async && !atomic. However,
> this is unnecessary, and __get_user_pages_fast is *much* faster
> because the regular get_user_pages takes pmd_lock/pte_lock.
> In fact, when many CPUs take a nested vmexit at the same time
> the contention on those locks is visible, and this patch removes
> about 25% (compared to 4.18) from vmexit.flat on a 16 vCPU
> nested guest.
>
> Suggested-by: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> virt/kvm/kvm_main.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 861bb20e8451..0f26ff7ddedb 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1343,18 +1343,16 @@ static inline int check_user_page_hwpoison(unsigned long addr)
> }
>
> /*
> - * The atomic path to get the writable pfn which will be stored in @pfn,
> - * true indicates success, otherwise false is returned.
> + * The fast path to get the writable pfn which will be stored in @pfn,
> + * true indicates success, otherwise false is returned. It's also the
> + * only part that runs if we can are in atomic context.
> */
> -static bool hva_to_pfn_fast(unsigned long addr, bool atomic, bool *async,
> - bool write_fault, bool *writable, kvm_pfn_t *pfn)
> +static bool hva_to_pfn_fast(unsigned long addr, bool write_fault,
> + bool *writable, kvm_pfn_t *pfn)
> {
> struct page *page[1];
> int npages;
>
> - if (!(async || atomic))
> - return false;
> -
> /*
> * Fast pin a writable pfn only if it is a write fault request
> * or the caller allows to map a writable pfn for a read fault
> @@ -1498,7 +1496,7 @@ static kvm_pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool *async,
> /* we can do it either atomically or asynchronously, not both */
> BUG_ON(atomic && async);
>
> - if (hva_to_pfn_fast(addr, atomic, async, write_fault, writable, &pfn))
> + if (hva_to_pfn_fast(addr, write_fault, writable, &pfn))
> return pfn;
>
> if (atomic)
>
Indeed for the !atomic case this looks perfectly valid. And also !async
should be fine as we there is nothing to wait for if the page is already
in memory.
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2018-07-30 8:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 15:46 Paolo Bonzini
2018-07-30 8:40 ` David Hildenbrand [this message]
2018-08-06 7:51 ` Xiao Guangrong
2018-08-06 11:44 ` Paolo Bonzini
2018-08-06 17:39 ` Andrea Arcangeli
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=65bee5ae-6bd8-38ff-d966-b1cf40d75d44@redhat.com \
--to=david@redhat.com \
--cc=junaids@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=vkuznets@redhat.com \
--cc=xiaoguangrong@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®