kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Chris Leduc <chris.leduc@ericsson.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Partial huge page backing with KVM/qemu
Date: Mon, 26 Aug 2013 11:02:09 +0300	[thread overview]
Message-ID: <20130826080209.GX8218@redhat.com> (raw)
In-Reply-To: <7F858974825DC945874D45551C161B941156D883@eusaamb105.ericsson.se>

On Mon, Aug 26, 2013 at 02:09:57AM +0000, Chris Leduc wrote:
> 
> 
> > -----Original Message-----
> > From: Gleb Natapov [mailto:gleb@redhat.com]
> > Sent: Sunday, August 25, 2013 1:52 AM
> > To: Chris Leduc
> > Cc: kvm@vger.kernel.org
> > Subject: Re: Partial huge page backing with KVM/qemu
> > 
> > On Sat, Aug 24, 2013 at 12:32:07AM +0000, Chris Leduc wrote:
> > > Hi - In a KVM/qemu environment is it possible for the host to back only a
> > portion of the guests memory with huge pages?  In some situations it may
> > not be desirable to back the entirety of a guest's memory with huge pages
> > (as can be done via libvirt memoryBacking option).
> > What are those situations?
> For example to limit a guest with 64GB of total memory to use 4GB of huge pages for fast lookup memory.  This takes advantage of the 4 TLB entries for 1G pages on a Sandy/Ivy Bridge processor to ensure a page walk is never necessary for this fast memory.  An example is a high performance data plane application.  The remainder of the less frequently accessed memory can be in normal pages.
> 
When two level paging (EPT) is in use combined mappings are stored in
TLB, not linear mappings (see 28.3.1). I am not sure those will ever
use 1G TLB.  Not with KVM anyway since KVM does not use 1G pages for EPT
tables since the chance to get as much of contiguous memory on a running
system is close to zero.

> > > What would be very useful is to request huge pages in the guest, either at
> > boot time or dynamically, and have the host back them with physical huge
> > pages, but not back the rest of the normal page guest memory with huge
> > pages from the host.
> > >
> > > The equivalent in Xen is setting allowsuperpage=1 on the hypervisor boot
> > line.
> > >
> > As far as I can tell this disables/enables use of huge pages by XEN vm, not
> > something you say you want.
> 
> The Xen documentation is not clear on this, but in practice this flag allows the host to back up guest huge page requests with physical huge pages.  So the guest could for example add hugepages=N to its boot line and these pages would be backed in the host with corresponding physical huge pages.
Allow me to be sceptical on this :) With shadow paging sure, same is true
for KVM: if guest maps memory with huge page and memory is contiguous on
a host too KVM will create huge shadow page, but with two level paging
hypervisor has no idea how guest's page tables look. The best it can do
is to map entire guest physical memory using huge pages.

> 
> From experimentation with KVM, requesting hugepages at guest boot time (without memory backing enabled) will result in guest hugepages backed by host normal pages.
What do you mean by "requesting hugepages at guest boot time" and how
have you checked that guest hugepages backed by host normal pages? Do
you have THP enabled? Without THP you need to back guest's memory with
huge pages using "–mem-path /hugepagesfs". But again only 2MB pages are
supported.

--
			Gleb.

  reply	other threads:[~2013-08-26  8:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-24  0:32 Partial huge page backing with KVM/qemu Chris Leduc
2013-08-25  8:52 ` Gleb Natapov
2013-08-26  2:09   ` Chris Leduc
2013-08-26  8:02     ` Gleb Natapov [this message]
2013-10-09  7:09       ` Gleb Natapov

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=20130826080209.GX8218@redhat.com \
    --to=gleb@redhat.com \
    --cc=chris.leduc@ericsson.com \
    --cc=kvm@vger.kernel.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).