hotplug-memory: refactor online_pages to separate zone growth from page onlining

The Xen balloon driver needs to separate the process of hot-installing memory into two phases: one to allocate the page structures and configure the zones, and another to actually online the pages of newly installed memory.

This patch splits up the innards of online_pages() into two pieces which correspond to these two phases. The behaviour of online_pages() itself is unchanged.

mm/memory_hotplug.c +3 -6

@@ -180,31 +180,35 @@
        return 0;
 }
 
-
-int online_pages(unsigned long pfn, unsigned long nr_pages)
+/* Tell anyone who's interested that we're onlining some memory */
+static int notify_going_online(unsigned long pfn, unsigned long nr_pages)
 {
-       unsigned long flags;
-       unsigned long onlined_pages = 0;
-       struct zone *zone;
-       int need_zonelists_rebuild = 0;
+       struct memory_notify arg;
        int nid;
        int ret;

Quoted 9 lines · Jeremy Fitzhardinge

The Xen balloon driver needs to separate the process of hot-installing memory into two phases: one to allocate the page structures and configure the zones, and another to actually online the pages of newly installed memory.

This patch splits up the innards of online_pages() into two pieces which correspond to these two phases. The behaviour of online_pages() itself is unchanged.

...

Quoted 20 lines

mm/memory_hotplug.c +3 -7

@@ -180,31 +180,35 @@
        return 0;
 }
 
-
-int online_pages(unsigned long pfn, unsigned long nr_pages)
+/* Tell anyone who's interested that we're onlining some memory */
+static int notify_going_online(unsigned long pfn, unsigned long nr_pages)
 {
-       unsigned long flags;
-       unsigned long onlined_pages = 0;
-       struct zone *zone;
-       int need_zonelists_rebuild = 0;
+       struct memory_notify arg;
        int nid;
        int ret;
-       struct memory_notify arg;
 

mm/memory_hotplug.c line 197

Quoted 9 lines

mm/memory_hotplug.c +1 -1

        arg.start_pfn = pfn;
        arg.nr_pages = nr_pages;
        arg.status_change_nid = -1;
-
+
        nid = page_to_nid(pfn_to_page(pfn));
        if (node_present_pages(nid) == 0)
                arg.status_change_nid = nid;
 

That's kind a weird line in the patch. How'd that get there? Why are you moving 'arg'?

This look OK, but it does add ~45 lines of code, and I'm not immediately sure how you're going to use it. Could you address that a bit?

I do kinda wish you'd take a real hard look at what the new functions are doing now. I'm not sure their current names are very good.

mm/memory_hotplug.c line 200

Quoted 3 lines

mm/memory_hotplug.c +2 -0

+/* Grow the zone to fit the expected amount of memory being added */
+static struct zone *online_pages_zone(unsigned long pfn, unsigned long nr_pages)
 

The comment is good, but the function name is not. :) How about grow_zone_span() or something?

mm/memory_hotplug.c line 203

Quoted 3 lines

mm/memory_hotplug.c +2 -0

+/* Mark a set of pages as online */
+unsigned long mark_pages_onlined(unsigned long pfn, unsigned long nr_pages)
 

Isn't the comment on this one a bit redundant? :)

This looks to me to have become the real online_pages() now. This function is what goes and individually onlines pages. If someone was trying to figure out whether to call online_pages() or mark_pages_onlined(), which one would they know to call?

mm/memory_hotplug.c line 213

Quoted 11 lines

mm/memory_hotplug.c +8 -1

-       if (onlined_pages)
+       if (onlined_pages) {
+               struct memory_notify arg;
+
+               arg.start_pfn = pfn;  /* ? */
+               arg.nr_pages = onlined_pages;
+               arg.status_change_nid = -1;  /* ? */
+
                memory_notify(MEM_ONLINE, &arg);
+       }
 

We should really wrap up memory notify:

static void memory_notify(int state, unsigned long start_pfn,
unsigned long nr_pages, int status_change_nid)

{
	struct memory_notify arg;
	arg.start_pfn = start_pfn;
	arg.nr_pages = nr_pages;
	arg.status_change_nid = status_change_nid;
	return the_current_memory_notify(state, &arg);
}

We can use that in a couple of spots, right?

Hi,

On Fri, 28 Mar 2008 17:00:05 -0700
Jeremy Fitzhardinge <[email protected]> wrote:

Review

Quoted 11 lines

(quoted diff) +8 -1

-	if (onlined_pages)
+	if (onlined_pages) {
+		struct memory_notify arg;
+
+		arg.start_pfn = pfn;  /* ? */
+		arg.nr_pages = onlined_pages;
+		arg.status_change_nid = -1;  /* ? */
+
 		memory_notify(MEM_ONLINE, &arg);
+	}

I think you should add "onlined" member instead of reusing nr_pages.

But, in general, I have no objection to this way.

Perhaps. Or we could get rid of it altogether. There's only a single user of the notifier (mm/slub.c), and given that it doesn't even use the MEM_ONLINE notifier, we could just drop this part.

Quoted 4 lines

Quoted 4 lines

(quoted diff) +3 -1

-	if (onlined_pages)
+	if (onlined_pages) {
+		struct memory_notify arg;
+

Quoted 9 lines

Review

Quoted 7 lines

(quoted diff) +5 -0

+		arg.start_pfn = pfn;  /* ? */
+		arg.nr_pages = onlined_pages;
+		arg.status_change_nid = -1;  /* ? */
+
 		memory_notify(MEM_ONLINE, &arg);
+	}

I think you should add "onlined" member instead of reusing nr_pages.

I suppose. What would I put into nr_pages? And anyway, there are no users for this notification...

Quoted 2 lines

But, in general, I have no objection to this way.

The refactoring in general?

My big remaining problem is how to disable the sysfs interface for this memory. I need to prevent any onlining via /sys/device/system/memory.

Quoted 2 lines · Jeremy Fitzhardinge

My big remaining problem is how to disable the sysfs interface for this memory. I need to prevent any onlining via /sys/device/system/memory.

I've been thinking about this some more, and I wish that you wouldn't just throw this interface away or completely disable it.

It actually
does *exactly* what you want in a way. :)

When the /memoryXX/ directory appears, that means that the hardware has found the memory, and that the 'struct page' is allocated and ready to be initialized.

When the OS actually wants to use the memory (initialize the 'struct page', and free_page() it), it does the 'echo online > /sys...'. Both the 'struct page' and the memory represented by it are untouched until the "online". This was originally in place to avoid fragmenting it immediately in the case that the system did not need it.

To me, it sounds like the only different thing that you want is to make sure that only partial sections are onlined. So, shall we work with the existing interfaces to online partial sections, or will we just disable it entirely when we see Xen?

For Xen and KVM, how does it get decided that the guest needs more memory? Is this guest or host driven? Both? How is the guest notified? Is guest userspace involved at all?

Quoted 6 lines · Dave Hansen

To me, it sounds like the only different thing that you want is to make sure that only partial sections are onlined. So, shall we work with the existing interfaces to online partial sections, or will we just disable it entirely when we see Xen?

Well, yes and no.

For the current balloon driver, it doesn't make much sense. It would add a fair amount of complexity without any real gain. It's currently based around alloc_page/free_page. When it wants to shrink the domain and give memory back to the host, it allocates pages, adds the page structures to a ballooned pages list, and strips off the backing memory and gives it to the host. Growing the domain is the converse: it gets pages from the host, pulls page structures off the list, binds them together and frees them back to the kernel. If it runs out of ballooned page structures, it hotplugs in some memory to add more.

That said, if (partial-)sections were much smaller - say 2-4 meg - and page migration/defrag worked reliably, then we could probably do without the balloon driver and do it all in terms of memory hot plug/unplug. That would give us a general mechanism which could either be driven from userspace, and/or have in-kernel Xen/kvm/s390/etc policy modules. Aside from small sections, the only additional requirement would be an online hook which can actually attach backing memory to the pages being onlined, rather than just assuming an underlying DIMM as current code does.

Quoted 3 lines

For Xen and KVM, how does it get decided that the guest needs more memory? Is this guest or host driven? Both? How is the guest notified? Is guest userspace involved at all?

In Xen, either the host or the guest can set the target size for the domain, which is capped by the host-set limit. Aside from possibly setting the target size, there's no usermode involvement in managing ballooning. The virtio balloon driver is similar, though from a quick look it seems to be entirely driven by the host side.

J

Quoted 6 lines · Dave Hansen

Quoted 3 lines · Jeremy Fitzhardinge

My big remaining problem is how to disable the sysfs interface for this memory. I need to prevent any onlining via /sys/device/system/memory.

Quoted 2 lines

I've been thinking about this some more, and I wish that you wouldn't just throw this interface away or completely disable it.

I had no intention of globally disabling it. I just need to disable it for my use case.

Quoted 5 lines

To me, it sounds like the only different thing that you want is to make sure that only partial sections are onlined. So, shall we work with the existing interfaces to online partial sections, or will we just disable it entirely when we see Xen?

Well, yes and no.

For the current balloon driver, it doesn't make much sense. It would add a fair amount of complexity without any real gain. It's currently based around alloc_page/free_page. When it wants to shrink the domain and give memory back to the host, it allocates pages, adds the page structures to a ballooned pages list, and strips off the backing memory and gives it to the host. Growing the domain is the converse: it gets pages from the host, pulls page structures off the list, binds them together and frees them back to the kernel. If it runs out of ballooned page structures, it hotplugs in some memory to add more.

That said, if (partial-)sections were much smaller - say 2-4 meg - and page migration/defrag worked reliably, then we could probably do without the balloon driver and do it all in terms of memory hot plug/unplug. That would give us a general mechanism which could either be driven from userspace, and/or have in-kernel Xen/kvm/s390/etc policy modules. Aside from small sections, the only additional requirement would be an online hook which can actually attach backing memory to the pages being onlined, rather than just assuming an underlying DIMM as current code does.

Quoted 11 lines · Jeremy Fitzhardinge

Quoted 9 lines · Dave Hansen

Quoted 3 lines · Jeremy Fitzhardinge

My big remaining problem is how to disable the sysfs interface for this memory. I need to prevent any onlining via /sys/device/system/memory.

I've been thinking about this some more, and I wish that you wouldn't just throw this interface away or completely disable it.

Quoted 2 lines

I had no intention of globally disabling it. I just need to disable it for my use case.

Right, but by disabling it for your case, you have given up all of the testing that others have done on it. Let's try and see if we can get the interface to work for you.

Quoted 6 lines

Quoted 6 lines

To me, it sounds like the only different thing that you want is to make sure that only partial sections are onlined. So, shall we work with the existing interfaces to online partial sections, or will we just disable it entirely when we see Xen?

Quoted 4 lines

Well, yes and no.

For the current balloon driver, it doesn't make much sense. It would add a fair amount of complexity without any real gain. It's currently based around alloc_page/free_page. When it wants to shrink the domain and give memory back to the host, it allocates pages, adds the page structures to a ballooned pages list, and strips off the backing memory and gives it to the host. Growing the domain is the converse: it gets pages from the host, pulls page structures off the list, binds them together and frees them back to the kernel. If it runs out of ballooned page structures, it hotplugs in some memory to add more.

How does this deal with things like present_pages in the zones? Does the total ram just grow with each hot-add, or does it grow on a per-page basis from the ballooning?

Quoted 2 lines

That said, if (partial-)sections were much smaller - say 2-4 meg - and page migration/defrag worked reliably, then we could probably do without the balloon driver and do it all in terms of memory hot plug/unplug. That would give us a general mechanism which could either be driven from userspace, and/or have in-kernel Xen/kvm/s390/etc policy modules. Aside from small sections, the only additional requirement would be an online hook which can actually attach backing memory to the pages being onlined, rather than just assuming an underlying DIMM as current code does.

Even with 1MB sections

and a flat sparsemem map, you're only looking at
~500k of overhead for the sparsemem storage. Less if you use vmemmap.

Quoted 14 lines · Dave Hansen

Quoted 12 lines · Jeremy Fitzhardinge

Quoted 10 lines · Dave Hansen

Quoted 4 lines · Jeremy Fitzhardinge

My big remaining problem is how to disable the sysfs interface for this memory. I need to prevent any onlining via /sys/device/system/memory.

I've been thinking about this some more, and I wish that you wouldn't just throw this interface away or completely disable it.

Quoted 8 lines

Quoted 3 lines

I had no intention of globally disabling it. I just need to disable it for my use case.

Right, but by disabling it for your case, you have given up all of the testing that others have done on it. Let's try and see if we can get the interface to work for you.

I suppose, but I'm not sure I see the point. What are the benefits of using this interface? You mentioned that the interface exists so that its possible to defer using a newly added piece of memory to avoid fragmentation. I suppose I can see the point of that

But in the xen-balloon case, the memory is added on-demand precisely when its about to be used, and then onlined in pieces as needed. Extending the usermode interface to allow partial onlining/offlining doesn't seem very useful for the case of physical hotplug memory, and its not at all clear how to do it in a useful way for the xen-balloon case. Particularly for offlining, since you'd need to guarantee that any page chosen for offlining isn't currently in use.

Quoted 19 lines

Quoted 8 lines

Quoted 6 lines

To me, it sounds like the only different thing that you want is to make sure that only partial sections are onlined. So, shall we work with the existing interfaces to online partial sections, or will we just disable it entirely when we see Xen?

Well, yes and no.

Quoted 10 lines

For the current balloon driver, it doesn't make much sense. It would add a fair amount of complexity without any real gain. It's currently based around alloc_page/free_page. When it wants to shrink the domain and give memory back to the host, it allocates pages, adds the page structures to a ballooned pages list, and strips off the backing memory and gives it to the host. Growing the domain is the converse: it gets pages from the host, pulls page structures off the list, binds them together and frees them back to the kernel. If it runs out of ballooned page structures, it hotplugs in some memory to add more.

Quoted 4 lines

How does this deal with things like present_pages in the zones? Does the total ram just grow with each hot-add, or does it grow on a per-page basis from the ballooning?

Well, there are two ways of looking at it:

either hot-plugging memory immediately adds pages, but they're also all immediately allocated and therefore unavailable for general use, or

the pages are notionally physically added as they're populated by the host

In principle they're equivalent, but I could imagine the former has the potential to make the VM waste time scanning unfreeable pages.

I'm not sure the patches I've posted are doing this stuff correctly either way.

Quoted 1 line

Quoted 1 line

That said, if (partial-)sections were much smaller - say 2-4 meg -

and

Quoted 1 line

Quoted 1 line

page migration/defrag worked reliably, then we could probably do

without

Quoted 8 lines

Quoted 7 lines

the balloon driver and do it all in terms of memory hot plug/unplug. That would give us a general mechanism which could either be driven from userspace, and/or have in-kernel Xen/kvm/s390/etc policy modules. Aside from small sections, the only additional requirement would be an online hook which can actually attach backing memory to the pages being onlined, rather than just assuming an underlying DIMM as current code does.

Quoted 1 line

Even with 1MB sections

1MB is too small. It shouldn't be smaller than the size of a large page.

Quoted 3 lines

and a flat sparsemem map, you're only looking at
~500k of overhead for the sparsemem storage. Less if you use vmemmap.

At the moment my concern is 32-bit x86, which doesn't support vmemmap or sections smaller than 512MB because of the shortage of page flags bits.

Quoted 4 lines

Quoted 4 lines

and a flat sparsemem map, you're only looking at
~500k of overhead for the sparsemem storage. Less if you use vmemmap.

Quoted 2 lines

At the moment my concern is 32-bit x86, which doesn't support vmemmap or sections smaller than 512MB because of the shortage of page flags bits.

Yeah, I forgot that we didn't have vmemmap on x86-32. Ugh.

OK, here's another idea: Xen (and the balloon driver) already handle a case where a guest boots up with 2GB of memory but only needs 1GB, right? It will balloon the guest down to 1GB from 2GB.

Why don't we just have hotplug work that way? When we want to take a guest from 1GB to 1GB+1 page (or whatever), we just hotplug the entire section (512MB or 1GB or whatever), actually online the whole thing, then make the balloon driver take it back to where it *should* be. That way we're completely reusing existing components that have do be able to handle this case anyway.

Yeah, this is suboptimal, an it has a possibility of fragmenting the memory, but it will only be used for the x86-32 case.

Quoted 7 lines

Why don't we just have hotplug work that way? When we want to take a guest from 1GB to 1GB+1 page (or whatever), we just hotplug the entire section (512MB or 1GB or whatever), actually online the whole thing, then make the balloon driver take it back to where it *should* be. That way we're completely reusing existing components that have do be able to handle this case anyway.

Quoted 3 lines

Yeah, this is suboptimal, an it has a possibility of fragmenting the memory, but it will only be used for the x86-32 case.

It also requires you actually have the memory on hand to populate the whole area. 512MB is still a significant chunk on a 2GB server; you may end up generating significant overall system memory pressure to scrape together the memory, only to immediately discard it again.

Quoted 11 lines · Jeremy Fitzhardinge

Quoted 11 lines

Why don't we just have hotplug work that way? When we want to take a guest from 1GB to 1GB+1 page (or whatever), we just hotplug the entire section (512MB or 1GB or whatever), actually online the whole thing, then make the balloon driver take it back to where it *should* be. That way we're completely reusing existing components that have do be able to handle this case anyway.

Yeah, this is suboptimal, an it has a possibility of fragmenting the memory, but it will only be used for the x86-32 case.

Quoted 2 lines

It also requires you actually have the memory on hand to populate the whole area. 512MB is still a significant chunk on a 2GB server; you may end up generating significant overall system memory pressure to scrape together the memory, only to immediately discard it again.

That's a very good point. Can we make it so that the hypervisors don't actually allocate the memory to the guest until its first touch? If the pages are on the freelist, their *contents* shouldn't be touched at all during the onlining process.

Dave Hansen wrote:
No, not in a Xen direct-pagetable guest. The guest actually sees real hardware page numbers (mfns) when the hypervisor gives it a page. By the time the hypervisor gives it a page reference, it already guaranteeing that the page is available for guest use. The only thing that we could do is prevent the guest from mapping the page, but that doesn't really achieve much.

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.

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?

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.

Quoted 2 lines

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

Quoted 3 lines · Jeremy Fitzhardinge

Dave Hansen wrote:
No, not in a Xen direct-pagetable guest. The guest actually sees real hardware page numbers (mfns) when the hypervisor gives it a page. By the time the hypervisor gives it a page reference, it already guaranteeing that the page is available for guest use. The only thing that we could do is prevent the guest from mapping the page, but that doesn't really achieve much.

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?

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.

Quoted 2 lines

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

-- Dave

Quoted 4 lines · Dave Hansen

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.

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 7 lines · Jeremy Fitzhardinge

Quoted 5 lines · Dave Hansen

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?

Quoted 2 lines

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.

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.

Quoted 2 lines

Everything also applies to x86-64.

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

Quoted 5 lines · Dave Hansen

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 didn't think x86-64 had a notion of highmem.

How do you prevent the pages from being used before they're ballooned out?

Quoted 4 lines

Quoted 1 line

Everything also applies to x86-64.

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

Right now, I'd rather have a single mechanism that works for both.

Quoted 6 lines

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 didn't think x86-64 had a notion of highmem.

How do you prevent the pages from being used before they're ballooned out?