Documentation/core-api/memory-hotplug.rst

4 Memory hotplug
7 Memory hotplug event notifier
10 Hotplugging events are sent to a notification queue.
12 There are six types of notification defined in ``include/linux/memory.h``:
15   Generated before new memory becomes available in order to be able to
16   prepare subsystems to handle memory. The page allocator is still unable
17   to allocate from the new memory.
23   Generated when memory has successfully brought online. The callback may
24   allocate pages from the new memory.
27   Generated to begin the process of offlining memory. Allocations are no
28   longer possible from the memory but some of the memory to be offlined
29   is still in use. The callback can be used to free memory known to a
30   subsystem from the indicated memory block.
33   Generated if MEM_GOING_OFFLINE fails. Memory is available again from
34   the memory block that we attempted to offline.
37   Generated after offlining memory is complete.
51 The first argument of the callback function (self) is a pointer to the block
52 of the notifier chain that points to the callback function itself.
64 - start_pfn is start_pfn of online/offline memory.
65 - nr_pages is # of pages of online/offline memory.
66 - status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
67   is (will be) set/clear, if this is -1, then nodemask status is not changed.
68 - status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask
69   is (will be) set/clear, if this is -1, then nodemask status is not changed.
70 - status_change_nid is set node id when N_MEMORY of nodemask is (will be)
71   set/clear. It means a new(memoryless) node gets new memory by online and a
72   node loses all memory. If this is -1, then nodemask status is not changed.
83 NOTIFY_BAD is used as response to the MEM_GOING_ONLINE, MEM_GOING_OFFLINE,
84 MEM_ONLINE, or MEM_OFFLINE action to cancel hotplugging. It stops
92 When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
93 the device_hotplug_lock should be held to:
95 - synchronize against online/offline requests (e.g. via sysfs). This way, memory
97   space once memory has been fully added. And when removing memory, we
99 - synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
102 device_hotplug_lock when adding memory and user space tries to online that
103 memory faster than expected:
105 - device_online() will first take the device_lock(), followed by
107 - add_memory_resource() will first take the mem_hotplug_lock, followed by
110 As the device is visible to user space before taking the device_lock(), this
113 onlining/offlining of memory should be done via device_online()/
114 device_offline() - to make sure it is properly synchronized to actions
115 via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
117 When adding/removing/onlining/offlining memory or adding/removing
118 heterogeneous/device memory, we should always hold the mem_hotplug_lock in
119 write mode to serialise memory hotplug (e.g. access to global/zone
122 In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
124 implementation, so code accessing memory can protect from that memory