Re: [PATCH RFC] hotplug-memory: refactor online_pages to separate zone growth from page onlining

[Dave Hansen <dave@linux.vnet.ibm.com>]

On Wed, 2008-04-02 at 14:35 -0700, Jeremy Fitzhardinge wrote:
> 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.

Wow.  So does Xen ever use PSE to map kernel data?  That sucks.

> > 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.

Yeah, but I'm just talking about hotplugged memory.  When we add it, we
don't have to map the added pages (since they're highmem) and don't have
to touch their contents and zero them out, either.  Then, the balloon
driver can notice that the memory is too large, and start to balloon it
down.

> >> 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.

Not really, though.  We don't have the page->flags shortage or lack of
vmemmap on x86_64.

-- Dave