linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: agraf@suse.de, benh@kernel.crashing.org, paulus@samba.org
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	kvm-ppc@vger.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault
Date: Sun, 29 Jun 2014 16:47:28 +0530	[thread overview]
Message-ID: <1404040655-12076-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> (raw)

Hi,

With the current code we do an expensive hash page table lookup on every
page fault resulting from a missing hash page table entry. A NO_HPTE
page fault can happen due to the below reasons:

1) Missing hash pte as per guest. This should be forwarded to the guest
2) MMIO hash pte. The address against which the load/store is performed
   should be emulated as a MMIO operation.
3) Missing hash pte because host swapped out the guest page.

We want to differentiate (1) from (2) and (3) so that we can speed up
page fault due to (1). Optimizing (1) will help in improving
the overall performance because that covers a large percentage of
the page faults.

To achieve the above we use virtual page calss protection mechanism for
covering (2) and (3). For both the above case we mark the hpte
valid, but associate the page with virtual page class index 30 and 31.
The authority mask register is configured such that class index 30 and 31
will have read/write denied. The above change results in a key fault
for (2) and (3). This allows us to forward a NO_HPTE fault directly to guest
without doing the expensive hash pagetable lookup.

For the test below:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

#define PAGES (40*1024)

int main()
{
	unsigned long size = getpagesize();
	unsigned long length = size * PAGES;
	unsigned long i, j, k = 0;

	for (j = 0; j < 10; j++) {
		char *c = mmap(NULL, length, PROT_READ|PROT_WRITE,
			       MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
		if (c == MAP_FAILED) {
			perror("mmap");
			exit(1);
		}
		for (i = 0; i < length; i += size)
			c[i] = 0;

		/* flush hptes */
		mprotect(c, length, PROT_WRITE);

		for (i = 0; i < length; i += size)
			c[i] = 10;

		mprotect(c, length, PROT_READ);

		for (i = 0; i < length; i += size)
			k += c[i];

		munmap(c, length);
	}
}

Without Fix:
----------
[root@qemu-pr-host ~]# time ./pfault

real    0m8.438s
user    0m0.855s
sys     0m7.540s
[root@qemu-pr-host ~]#


With Fix:
--------
[root@qemu-pr-host ~]# time ./pfault

real    0m7.833s
user    0m0.782s
sys     0m7.038s
[root@qemu-pr-host ~]#



Aneesh Kumar K.V (6):
  KVM: PPC: BOOK3S: HV: Clear hash pte bits from do_h_enter callers
  KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect
  KVM: PPC: BOOK3S: HV: Remove dead code
  KVM: PPC: BOOK3S: HV: Use new functions for mapping/unmapping hpte in
    host
  KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte
    during an hpte update
  KVM: PPC: BOOK3S: HV: Use virtual page class protection mechanism for
    host fault and mmio

 arch/powerpc/include/asm/kvm_book3s_64.h |  97 +++++++++++++++++-
 arch/powerpc/include/asm/kvm_host.h      |   1 +
 arch/powerpc/include/asm/reg.h           |   1 +
 arch/powerpc/kernel/asm-offsets.c        |   1 +
 arch/powerpc/kvm/book3s_64_mmu_hv.c      |  99 ++++++++++++------
 arch/powerpc/kvm/book3s_hv.c             |   1 +
 arch/powerpc/kvm/book3s_hv_rm_mmu.c      | 166 +++++++++++++++++++++----------
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  | 100 +++++++++++++++++--
 8 files changed, 371 insertions(+), 95 deletions(-)

-- 
1.9.1

             reply	other threads:[~2014-06-29 11:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-29 11:17 Aneesh Kumar K.V [this message]
2014-06-29 11:17 ` [PATCH 1/6] KVM: PPC: BOOK3S: HV: Clear hash pte bits from do_h_enter callers Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH] KVM: PPC: BOOK3S: HV: Update compute_tlbie_rb to handle 16MB base page Aneesh Kumar K.V
2014-07-02  4:00   ` Paul Mackerras
2014-06-29 11:17 ` [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect Aneesh Kumar K.V
2014-07-02  4:50   ` Paul Mackerras
2014-07-02 12:12     ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 3/6] KVM: PPC: BOOK3S: HV: Remove dead code Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 4/6] KVM: PPC: BOOK3S: HV: Use new functions for mapping/unmapping hpte in host Aneesh Kumar K.V
2014-07-02  4:28   ` Paul Mackerras
2014-07-02 11:49     ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update Aneesh Kumar K.V
2014-07-02  5:41   ` Paul Mackerras
2014-07-02 11:57     ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 6/6] KVM: PPC: BOOK3S: HV: Use virtual page class protection mechanism for host fault and mmio Aneesh Kumar K.V
2014-06-29 11:26 ` [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault Benjamin Herrenschmidt
2014-06-29 16:57   ` Aneesh Kumar K.V

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=1404040655-12076-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    /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;
as well as URLs for NNTP newsgroup(s).