Re: [PATCH] GSoC 2010 - Memory hotplug support for Xen guests - third fully working version

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jeremy Fitzhardinge
Date: Thursday, August 12, 2010 - 5:46 pm

On 08/11/2010 06:22 PM, Daniel Kiper wrote:

Thanks.  I'll paste in the full diff and comment on that rather than 
this incremental update.




So does this mean you only support adding a single hotplug region?  What 
happens if your initial increase wasn't enough and you want to add 
more?  Would you make this a list of hot-added memory or something?

But I'm not even quite sure why you need to keep this as global data.


So this just reserves enough resource to satisfy the current outstanding 
requirement?  That's OK if we can repeat it, but it looks like it will 
only do this once?


Does this need to be section aligned, with a section size?  Or is any old place OK?



Allocating all the memory here seems sub-optimal.



Why is this done separately from the reservation/allocation from xen?


Is the entire reserved memory range guaranteed to be within one node?

I see that this function has multiple definitions depending on a number 
of config settings.  Do we care about what definition it has?


Are the pages available for allocation by the rest of the kernel from 
this point on?

Which function allocates the actual page structures?


What does this do?  How is it different from what online_pages() does?


Why can't this be done in allocate_additional_memory()?


In your earlier, patch I think you made the firmware_map_add_hotplug() 
be specific to add_memory, but now you have it in __add_memory.  Does it 
make a difference either way?


As before, this all looks reasonably good.  I think the next steps 
should be:

   1. identify how to incrementally allocate the memory from Xen, rather
      than doing it at hotplug time
   2. identify how to disable the sysfs online interface for Xen
      hotplugged memory

For 1., I think the code should be something like:

increase_address_space(unsigned long pages)
{
	- reserve resource for memory section
	- online section
	for each page in section {
		online page
		mark page structure allocated
		add page to ballooned_pages list
		balloon_stats.balloon_(low|high)++;
	}
}


The tricky part is making sure that the memory for the page structures 
has been populated so it can be used.  Aside from that, there should be 
no need to have another call to 
HYPERVISOR_memory_op(XENMEM_populate_physmap, ...) aside from the 
existing one.

Or to look at it another way, memory hotplug is the mechanism for 
increasing the amount of available physical address space, but 
ballooning is the way to increase the number of allocated pages.  They 
are orthogonal.


2 requires a deeper understanding of the existing hotplug code.  It 
needs to be refactored so that you can use the core hotplug machinery 
without enabling the sysfs page-onlining mechanism, while still leaving 
it available for physical hotplug.  In the short term, having a boolean 
to disable the onlining mechanism is probably the pragmatic solution, so 
the balloon code can simply disable it.

Thanks,
     J
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] GSoC 2010 - Memory hotplug support for Xen gue ..., Jeremy Fitzhardinge, (Thu Aug 12, 5:43 pm)
Re: [PATCH] GSoC 2010 - Memory hotplug support for Xen gue ..., Jeremy Fitzhardinge, (Thu Aug 12, 5:46 pm)
Re: [Xen-devel] Re: [PATCH] GSoC 2010 - Memory hotplug sup ..., Jeremy Fitzhardinge, (Thu Aug 12, 5:48 pm)
Re: [PATCH] GSoC 2010 - Memory hotplug support for Xen gue ..., Jeremy Fitzhardinge, (Wed Aug 25, 2:33 pm)
Re: [PATCH] GSoC 2010 - Memory hotplug support for Xen gue ..., KAMEZAWA Hiroyuki, (Wed Aug 25, 6:23 pm)