All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jan Beulich <JBeulich@novell.com>
Cc: Dave McCracken <dcm@mccr.org>,
	Xen Developers List <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] Add 2M page support to Xen balloon	 driver
Date: Wed, 17 Jun 2009 09:40:36 -0700	[thread overview]
Message-ID: <4A391C84.2070807@goop.org> (raw)
In-Reply-To: <4A38C87D020000780000632D@vpn.id2.novell.com>

On 06/17/09 01:42, Jan Beulich wrote:
>> This patch adds a kernel command line option "balloon_hugepages" that, when
>> enabled, will make the balloon driver work in 2M pages (ie hugepages).  This
>> will work in conjunction with the "superpages" domain creation option so once
>> a domain is created with 2M contiguous pages it will continue to free and re-
>> allocate at the 2M page size.
>>
>> Note that the current hypervisor code does not allow 2M page allocations for
>> all guest domains.  Keir has agreed to change the hypervisor to allow them,
>> but for now "balloon_hugepages" should only be specified on hypervisors that
>> have this change.
>>      
>
> How would that work with future (currently only some piece of dead code in
> xen-netfront.c does so) code altering the p2m map outside of the balloon
> driver? Shouldn't you at least verify the large page you allocated is indeed
> machine-contiguous?
>    

I have some experimental patches to move memory around at boot time to 
avoid e820 holes.  It would need to take care with 2M pages.  The dma 
code also updates the p2m map when it makes a page range contiguous.

> Also, after reasonably long uptime and on a reasonably loaded machine -
> how good are the chances you would be able to allocate a large page
> through alloc_pages() in the first place?
>    

I think you lose the ability to allocate 2M pages pretty quickly; 
probably only a few mins on a moderately loaded server (depends on total 
memory size, of course).  On the other hand, the VM can now relocate 
user and pagecache pages to try and satisfy large memory allocations, so 
maybe it can manage it for longer or even indefinitely.

     J

      reply	other threads:[~2009-06-17 16:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 15:53 [PATCH] Add 2M page support to Xen balloon driver Dave McCracken
2009-06-17  8:42 ` Jan Beulich
2009-06-17 16:40   ` Jeremy Fitzhardinge [this message]

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=4A391C84.2070807@goop.org \
    --to=jeremy@goop.org \
    --cc=JBeulich@novell.com \
    --cc=dcm@mccr.org \
    --cc=xen-devel@lists.xensource.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.