questions about memory hotplug

Shaohua Li shaohua.li at intel.com
Sat Jul 30 05:30:55 EDT 2011


On Sat, Jul 30, 2011 at 06:12:31AM +0800, Larry Bassel wrote:
> We want to handle the following 2 use cases we have on
> some of our (ARM) platforms:
> 
> 1. A platform where part of the memory may be powered
> off. The location and size of this memory is not known
> until the kernel parses the memory tags (there aren't
> any non-standard tags used, but the memory layout and
> a memory bank size which is obtained from HW are used
> to figure out where and how large this memory is). All
> of this memory must either be on or off. For a given
> configuration the location of this memory can't be moved.
> 
> 2. A (different) platform where part of the memory
> is occasionally needed as a large physically contiguous 
> block, but usually is not (and then should be usable
> by the kernel as normal memory). When the memory is
> needed for the contiguous block, the pages in this
> range currently being used by the kernel will
> need to be migrated out.
> 
> The size of this is known at compile time and can be
> placed at any reasonable place in memory (but should
> be SPARSEMEM section aligned -- its size may however
> not be a power of 2 and thus this memory could
> span more than one section). This memory will not be
> powered off, but must either be completely used for
> one purpose or the other.
> 
> The size of memory in question for #1 is generally
> much larger than that of #2.
> 
> Memory hotplug/hotremove (logical and physical for #1,
> only logical for #2) approximately solves these problems,
> but there is some functionality we need that AFAIK is
> not present:
> 
> * The memory in #1 and #2 above must be in a movable
> zone so that the chance of migration is maximized.
> I'm familiar with the kernelcore= and movablecore=
> commandline options, but they don't do what is necessary
> here, because we need control on where the movable zone
> is formed as well as the size. Also the location and size
> of these special memory areas is not known until the
> kernel comes up (in #1 it is conceivable that the bootloader
> could locate the memory that can be powered on and off and
> pass it in via some commandline option, but AFAICT this won't
> work at all for #2).
> 
> One could hack up find_zone_movable_pfns_for_nodes() presumably,
> but I wonder if there is an already existing way of doing
> this (or at least a clean extension to the current
> functionality that someone might suggest).
> 
> Would CONFIG_ARCH_POPULATES_NODE_MAP help here? Does anyone
> use this? It doesn't seem to be in any defconfig or Kconfig
> on 3.0 (or earlier versions I've looked at).
> 
> Perhaps CMA (which is not merged yet and AFAIK still has some
> issues on ARM) might handle #2 better than memory
> hotplug/hotremove. Or is there a better way to handle #2
> than either CMA or memory hotplug?
is such memory always at the end of memory? if yes, such memory
can be added to MOVABLE_ZONE.
or if such memory can be at the middle of memory, maybe we can add
a new mirgate type, the migrate type is movable but other type allocation
can't fallback into.

Thanks,
Shaohua



More information about the linux-arm-kernel mailing list