From: Avi Kivity <avi@redhat.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] kvm, x86: use ro page and don't copy shared page
Date: Wed, 09 Jun 2010 12:28:11 +0300 [thread overview]
Message-ID: <4C0F5EAB.3030401@redhat.com> (raw)
In-Reply-To: <4C0F4883.3010100@cn.fujitsu.com>
On 06/09/2010 10:53 AM, Lai Jiangshan wrote:
> When page fault, we always call get_user_pages(write=1).
>
> Actually, we don't need to do this when it is not write fault.
> get_user_pages(write=1) will cause shared page(ksm) copied.
> If this page is not modified in future, this copying and the copied page
> are just wasted. Ksm may scan and merge them and may cause thrash.
>
> This patch is not for inclusion, because I know nothing about mmio
> and this patch includes a "workaround" which ensures mmio pfns
> are always writable in tdp_page_fault().
> The guest can't even boot up without this workaround.
>
mmio pfns are used for device assignment. These are host pfns that
don't have a struct page, instead they belong to a device BAR.
I don't understand why you see a failure since they aren't even present
on guests without assigned devices.
> @@ -2357,7 +2359,12 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t gpa,
>
> mmu_seq = vcpu->kvm->mmu_notifier_seq;
> smp_rmb();
> - pfn = kvm_get_pfn_for_gfn(vcpu->kvm, gfn, 1);
> + pfn = kvm_get_pfn_for_gfn(vcpu->kvm, gfn, error_code& PFERR_WRITE_MASK);
>
This is a pessimization, since now we may need two faults per page, one
to page it in read-only and another to establish write access.
May not be so bad for tdp, but will surely reduce performance on shadow.
The way I think it should be improved, is to extend
get_user_pages_fast() to also return the pte. So now, if we get a page
for read, but it happens to have a writeable/dirty pte, we can still
allow write access in the spte.
> + if (!(error_code& PFERR_WRITE_MASK)&& kvm_is_mmio_pfn(pfn)) {
> + kvm_release_pfn_clean(pfn);
> + /* I don't know why we have to ensure mmio pfns are always writable. */
> + pfn = kvm_get_pfn_for_gfn(vcpu->kvm, gfn, 1);
> + }
>
Wierd. For what gfn/pfns does this trigger?
In general this is a great optimization.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-06-09 9:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 7:53 [RFC PATCH 2/2] kvm, x86: use ro page and don't copy shared page Lai Jiangshan
2010-06-09 9:28 ` Avi Kivity [this message]
2010-06-10 2:47 ` Lai Jiangshan
2010-06-10 11:19 ` Lai Jiangshan
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=4C0F5EAB.3030401@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=laijs@cn.fujitsu.com \
--cc=mtosatti@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.