On 10/28/2019 01:55 PM, Anshuman Khandual wrote: > There is a mechanism in ACPI for this i.e ACPI_SRAT_MEM_HOT_PLUGGABLE. > > Lets re-evaluate the situation here from scratch. Memory can be classified as > boot and runtime because it impacts the way in which kernel allocations, zone > initializations are treated. Boot memory deals with kernel allocation before > zone init happens where as runtime memory might choose which zone to get into > right away. > > (1) Boot memory > > - Non-movable > > - Normal memblocks > - All kernel allocations come here > - Become ZONE_NORMAL/DMA/DMA32 at runtime > > - Never removable because isolation and hence migration impossible > - Removal protection because of the zone classification > > - Movable (ACPI_SRAT_MEM_HOT_PLUGGABLE) > > - Memblock will be marked with MEMBLOCK_HOTPLUG > - Memblock allocations tried to be avoided (reversing the memblock order etc) > - Become ZONE_MOVABLE at runtime > > - Removable [1] There is another way in which boot memory can be created as ZONE_MOVABLE irrespective of whether the firmware (ACPI/OF) had asked for it or not. This is achieved with "kernelcore" or "movablecore" kernel command line options where the administrator exclusively asks for sections of memory to be converted as ZONE_MOVABLE. This creates some of the memory block devices in /sys/devices/system/memory as removable (ZONE_MOVABLE). IIUC this is mutually exclusive with respect to removable boot memory creation with "movable_node" kernel command line option with firmware tagged hot pluggable memory sections (ACPI_SRAT_MEM_HOT_PLUGGABLE). Details here: mm/page_alloc.c find_zone_movable_pfns_for_nodes() Now, this boils down to the fact whether firmware will ever request for removal of boot memory sections which was never tagged as hotpluggable by the firmware during boot. Wondering if tagging portions of boot memory as ZONE_MOVABLE might have any other use case if they are never to be hot removed. Will continue looking into ACPI/OF memory hotplug scenarios.
