From: Joerg Roedel <joro@8bytes.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>, Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] Support for GB pages in KVM
Date: Sat, 28 Mar 2009 22:49:00 +0100 [thread overview]
Message-ID: <20090328214900.GE31080@8bytes.org> (raw)
In-Reply-To: <20090328214008.GB4694@amt.cnet>
On Sat, Mar 28, 2009 at 06:40:08PM -0300, Marcelo Tosatti wrote:
> On Fri, Mar 27, 2009 at 03:31:52PM +0100, Joerg Roedel wrote:
> > Hi,
> >
> > this patchset extends the KVM MMU implementation to support 1GB pages as
> > supported by AMD family 16 processors. These patches enable support for
> > 1 GB pages with Nested Paging. Support for these pages in the shadow
> > paging code was also developed but does not run stable yet. The patch
> > for shadow-paging support is not included in this series and will be
> > sent out seperatly.
>
> Looks generally sane. I'm not sure its even worthwhile to support
> GBpages with softmmu, because the chance of finding an area without
> shadowed (write protected) pages is much smaller than with 2MB pages.
Thanks for your review.
The idea behind GB pages in softmmu code was to provide GB pages to the
guest even if hardware does not support it. This would work better with
live migration (Only case where we wouldn't have gbpages then would be
vmx with ept enabled).
> Have any numbers to share?
No numbers I fully trust by now. I measured a 32% improvement in
kernbench using nested pages backed with gb pages. I will do some more
measurements and share some more solid numbers.
Joerg
next prev parent reply other threads:[~2009-03-28 21:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-27 14:31 [PATCH 0/7] Support for GB pages in KVM Joerg Roedel
2009-03-27 14:31 ` [PATCH 1/7] hugetlb: export vma_kernel_pagesize to modules Joerg Roedel
2009-03-27 14:31 ` [PATCH 2/7] kvm mmu: infrastructure changes for multiple huge page support Joerg Roedel
2009-03-29 11:38 ` Avi Kivity
2009-03-27 14:31 ` [PATCH 3/7] kvm mmu: add page size parameter to rmap_remove Joerg Roedel
2009-03-27 14:31 ` [PATCH 4/7] kvm mmu: implement necessary data structures for second huge page accounting Joerg Roedel
2009-03-29 11:45 ` Avi Kivity
2009-03-29 13:03 ` Joerg Roedel
2009-03-29 13:15 ` Avi Kivity
2009-03-29 13:32 ` Joerg Roedel
2009-03-29 13:26 ` Avi Kivity
2009-03-29 13:37 ` Avi Kivity
2009-03-27 14:31 ` [PATCH 5/7] kvm mmu: add support for 1GB pages to direct mapping paths Joerg Roedel
2009-03-29 11:49 ` Avi Kivity
2009-03-27 14:31 ` [PATCH 6/7] kvm mmu: enabling 1GB pages by extending backing_size funtion Joerg Roedel
2009-03-29 11:51 ` Avi Kivity
2009-03-27 14:31 ` [PATCH 7/7] kvm x86: report 1GB page support to userspace Joerg Roedel
2009-03-29 11:54 ` Avi Kivity
2009-03-29 12:45 ` Joerg Roedel
2009-03-29 12:49 ` Avi Kivity
2009-03-29 12:54 ` Joerg Roedel
2009-03-29 13:00 ` Avi Kivity
2009-03-28 21:40 ` [PATCH 0/7] Support for GB pages in KVM Marcelo Tosatti
2009-03-28 21:49 ` Joerg Roedel [this message]
2009-03-29 12:03 ` Avi Kivity
2009-03-29 12:47 ` Joerg Roedel
2009-03-29 12:01 ` Avi Kivity
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=20090328214900.GE31080@8bytes.org \
--to=joro@8bytes.org \
--cc=avi@redhat.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox