From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Yasunori Goto <y-goto@jp.fujitsu.com>,
Christoph Lameter <clameter@sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Anthony Liguori <anthony@codemonkey.ws>,
Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH RFC] hotplug-memory: refactor online_pages to separate zone growth from page onlining
Date: Wed, 02 Apr 2008 14:35:42 -0700 [thread overview]
Message-ID: <47F3FC2E.7090806@goop.org> (raw)
In-Reply-To: <1207171050.23710.48.camel@nimitz.home.sr71.net>
Dave Hansen wrote:
> Oh, once we've let Linux establish ptes to it, we've required that the
> hypervisor have it around? How does that work with the balloon driver?
> Do we destroy the ptes when giving balloon memory back to the
> hypervisor?
>
Yep. It removes any mapping before handing it back to the hypervisor.
> If we're talking about i386, then we're set. We don't map the hot-added
> memory at all because we only add highmem on i386. The only time we map
> these pages is *after* we actually allocate them when they get mapped
> into userspace or used as vmalloc() or they're kmap()'d.
>
Well, the balloon driver can balloon out lowmem pages, so we have to
deal with mappings either way. But balloon+hotplug would work
identically on x86-64, so all pages are mapped.
>> I think we're getting off track here; this is a lot of extra complexity
>> to justify allowing usermode to use /sys to online a chunk of hotplugged
>> memory.
>>
>
> Either that, or we're going to develop the entire Xen/kvm memory hotplug
> architecture around the soon-to-be-legacy i386 limitations. :)
Everything also applies to x86-64.
J
next prev parent reply other threads:[~2008-04-02 21:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-29 0:00 [PATCH RFC] hotplug-memory: refactor online_pages to separate zone growth from page onlining Jeremy Fitzhardinge
2008-03-29 0:47 ` Dave Hansen
2008-03-29 2:08 ` Jeremy Fitzhardinge
2008-03-29 6:01 ` Dave Hansen
2008-03-29 16:06 ` Dave Hansen
2008-03-29 23:53 ` Jeremy Fitzhardinge
2008-03-30 0:26 ` Anthony Liguori
2008-03-31 16:42 ` Dave Hansen
2008-03-31 18:06 ` Jeremy Fitzhardinge
2008-04-01 7:17 ` Yasunori Goto
2008-04-02 18:46 ` Dave Hansen
2008-04-02 18:52 ` Jeremy Fitzhardinge
2008-04-02 18:59 ` Dave Hansen
2008-04-02 21:03 ` Jeremy Fitzhardinge
2008-04-02 21:17 ` Dave Hansen
2008-04-02 21:35 ` Jeremy Fitzhardinge [this message]
2008-04-02 21:43 ` Dave Hansen
2008-04-02 22:13 ` Jeremy Fitzhardinge
2008-04-02 23:27 ` Dave Hansen
2008-04-03 7:03 ` KAMEZAWA Hiroyuki
2008-04-02 21:36 ` Anthony Liguori
2008-03-29 4:38 ` KAMEZAWA Hiroyuki
2008-03-29 5:48 ` Jeremy Fitzhardinge
2008-03-29 6:26 ` KAMEZAWA Hiroyuki
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=47F3FC2E.7090806@goop.org \
--to=jeremy@goop.org \
--cc=anthony@codemonkey.ws \
--cc=clameter@sgi.com \
--cc=dave@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=y-goto@jp.fujitsu.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