[RFC] Memory hotplug support for ARM64

From: Maciej Bielski
Date: Thu Nov 17 2016 - 02:08:59 EST


Dear All,

We are working on a series of patches that aims for implementing memory
hotplug (also hotremove after) functionality for ARM64 CPUs. There are already
existing ARM64 platforms with SO-DIMMs RAM bricks that could use such feature
([2], for example). Except for that, we would like to use it to provide runtime RAM
provisioning for Linux/KVM guests.

The process how to online new range of memory addresses is described in
Documentation/memory-hotplug.txt The idea is to make available new range of
addresses at runtime, after the brick is physically plugged in and it can be
performed via sysfs interface (more detailed description in documentation).

This feature is not currently available for ARM64 processors (the
implementation of architecture specific functions like `arch_add_memory()`
is missing for that platform). Our analysis so far has identified no technical
obstacle in porting memory hotplug to arm64, but probably this feature
was not highly desirable in the past, with ARM CPUs being deployed mostly on
portable devices without SO-DIMM slots.

Nowadays, this may change with ARM64 platform trying to enter server
market [1][2], where runtime memory reconfiguration is very important.
First, typically a server contains multiple SO-DIMM slots so additional RAM can be
physically attached. Second, it needs to be done while the machine is
running since often reboots are not acceptable in a data center. Trying to find
existing efforts towards this direction, we have only discovered that
the lack of memory hotplug/hotremove has been already spotted and mentioned as a
nice-to-have at least [3][4] but no working implementation has been found
published.

Therefore, we have planned to undertake the task of implementing kernel
support for RAM hotplug/hotunplug on ARM64 platform and achieved first optimistic
results. This particular development is performed within the scope of the
dReDBox - EC project under H2020 framework [5].

Do you see value in including such work in the mainline kernel? Any
comment is more than welcome (please add me to CC).


[1] http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Japan_2016_ARMv4.pdf
[2] http://www.cavium.com/ThunderX_ARM_Processors.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/382137.html
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/341865.html
[5] http://www.dredbox.eu/


BR,

--
Maciej Bielski