| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 1 | ============== | 
|  | 2 | Memory Hotplug | 
|  | 3 | ============== | 
|  | 4 |  | 
| Yasunori Goto | 10020ca | 2007-10-21 16:41:36 -0700 | [diff] [blame] | 5 | Created:					Jul 28 2007 | 
|  | 6 | Add description of notifier of memory hotplug	Oct 11 2007 | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 7 |  | 
|  | 8 | This document is about memory hotplug including how-to-use and current status. | 
|  | 9 | Because Memory Hotplug is still under development, contents of this text will | 
|  | 10 | be changed often. | 
|  | 11 |  | 
|  | 12 | 1. Introduction | 
|  | 13 | 1.1 purpose of memory hotplug | 
|  | 14 | 1.2. Phases of memory hotplug | 
|  | 15 | 1.3. Unit of Memory online/offline operation | 
|  | 16 | 2. Kernel Configuration | 
|  | 17 | 3. sysfs files for memory hotplug | 
|  | 18 | 4. Physical memory hot-add phase | 
|  | 19 | 4.1 Hardware(Firmware) Support | 
|  | 20 | 4.2 Notify memory hot-add event by hand | 
|  | 21 | 5. Logical Memory hot-add phase | 
|  | 22 | 5.1. State of memory | 
|  | 23 | 5.2. How to online memory | 
|  | 24 | 6. Logical memory remove | 
|  | 25 | 6.1 Memory offline and ZONE_MOVABLE | 
|  | 26 | 6.2. How to offline memory | 
|  | 27 | 7. Physical memory remove | 
| Yasunori Goto | 10020ca | 2007-10-21 16:41:36 -0700 | [diff] [blame] | 28 | 8. Memory hotplug event notifier | 
|  | 29 | 9. Future Work List | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 30 |  | 
|  | 31 | Note(1): x86_64's has special implementation for memory hotplug. | 
|  | 32 | This text does not describe it. | 
|  | 33 | Note(2): This text assumes that sysfs is mounted at /sys. | 
|  | 34 |  | 
|  | 35 |  | 
|  | 36 | --------------- | 
|  | 37 | 1. Introduction | 
|  | 38 | --------------- | 
|  | 39 |  | 
|  | 40 | 1.1 purpose of memory hotplug | 
|  | 41 | ------------ | 
|  | 42 | Memory Hotplug allows users to increase/decrease the amount of memory. | 
|  | 43 | Generally, there are two purposes. | 
|  | 44 |  | 
|  | 45 | (A) For changing the amount of memory. | 
|  | 46 | This is to allow a feature like capacity on demand. | 
|  | 47 | (B) For installing/removing DIMMs or NUMA-nodes physically. | 
|  | 48 | This is to exchange DIMMs/NUMA-nodes, reduce power consumption, etc. | 
|  | 49 |  | 
|  | 50 | (A) is required by highly virtualized environments and (B) is required by | 
|  | 51 | hardware which supports memory power management. | 
|  | 52 |  | 
|  | 53 | Linux memory hotplug is designed for both purpose. | 
|  | 54 |  | 
|  | 55 |  | 
|  | 56 | 1.2. Phases of memory hotplug | 
|  | 57 | --------------- | 
|  | 58 | There are 2 phases in Memory Hotplug. | 
|  | 59 | 1) Physical Memory Hotplug phase | 
|  | 60 | 2) Logical Memory Hotplug phase. | 
|  | 61 |  | 
|  | 62 | The First phase is to communicate hardware/firmware and make/erase | 
|  | 63 | environment for hotplugged memory. Basically, this phase is necessary | 
|  | 64 | for the purpose (B), but this is good phase for communication between | 
|  | 65 | highly virtualized environments too. | 
|  | 66 |  | 
|  | 67 | When memory is hotplugged, the kernel recognizes new memory, makes new memory | 
|  | 68 | management tables, and makes sysfs files for new memory's operation. | 
|  | 69 |  | 
|  | 70 | If firmware supports notification of connection of new memory to OS, | 
|  | 71 | this phase is triggered automatically. ACPI can notify this event. If not, | 
|  | 72 | "probe" operation by system administration is used instead. | 
|  | 73 | (see Section 4.). | 
|  | 74 |  | 
|  | 75 | Logical Memory Hotplug phase is to change memory state into | 
| Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 76 | available/unavailable for users. Amount of memory from user's view is | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 77 | changed by this phase. The kernel makes all memory in it as free pages | 
|  | 78 | when a memory range is available. | 
|  | 79 |  | 
|  | 80 | In this document, this phase is described as online/offline. | 
|  | 81 |  | 
| Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 82 | Logical Memory Hotplug phase is triggered by write of sysfs file by system | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 83 | administrator. For the hot-add case, it must be executed after Physical Hotplug | 
|  | 84 | phase by hand. | 
|  | 85 | (However, if you writes udev's hotplug scripts for memory hotplug, these | 
|  | 86 | phases can be execute in seamless way.) | 
|  | 87 |  | 
|  | 88 |  | 
|  | 89 | 1.3. Unit of Memory online/offline operation | 
|  | 90 | ------------ | 
|  | 91 | Memory hotplug uses SPARSEMEM memory model. SPARSEMEM divides the whole memory | 
|  | 92 | into chunks of the same size. The chunk is called a "section". The size of | 
|  | 93 | a section is architecture dependent. For example, power uses 16MiB, ia64 uses | 
|  | 94 | 1GiB. The unit of online/offline operation is "one section". (see Section 3.) | 
|  | 95 |  | 
|  | 96 | To determine the size of sections, please read this file: | 
|  | 97 |  | 
|  | 98 | /sys/devices/system/memory/block_size_bytes | 
|  | 99 |  | 
|  | 100 | This file shows the size of sections in byte. | 
|  | 101 |  | 
|  | 102 | ----------------------- | 
|  | 103 | 2. Kernel Configuration | 
|  | 104 | ----------------------- | 
|  | 105 | To use memory hotplug feature, kernel must be compiled with following | 
|  | 106 | config options. | 
|  | 107 |  | 
|  | 108 | - For all memory hotplug | 
|  | 109 | Memory model -> Sparse Memory  (CONFIG_SPARSEMEM) | 
|  | 110 | Allow for memory hot-add       (CONFIG_MEMORY_HOTPLUG) | 
|  | 111 |  | 
|  | 112 | - To enable memory removal, the followings are also necessary | 
|  | 113 | Allow for memory hot remove    (CONFIG_MEMORY_HOTREMOVE) | 
|  | 114 | Page Migration                 (CONFIG_MIGRATION) | 
|  | 115 |  | 
|  | 116 | - For ACPI memory hotplug, the followings are also necessary | 
|  | 117 | Memory hotplug (under ACPI Support menu) (CONFIG_ACPI_HOTPLUG_MEMORY) | 
|  | 118 | This option can be kernel module. | 
|  | 119 |  | 
|  | 120 | - As a related configuration, if your box has a feature of NUMA-node hotplug | 
|  | 121 | via ACPI, then this option is necessary too. | 
|  | 122 | ACPI0004,PNP0A05 and PNP0A06 Container Driver (under ACPI Support menu) | 
|  | 123 | (CONFIG_ACPI_CONTAINER). | 
|  | 124 | This option can be kernel module too. | 
|  | 125 |  | 
|  | 126 | -------------------------------- | 
| Gary Hade | c04fc58 | 2009-01-06 14:39:14 -0800 | [diff] [blame] | 127 | 4 sysfs files for memory hotplug | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 128 | -------------------------------- | 
|  | 129 | All sections have their device information under /sys/devices/system/memory as | 
|  | 130 |  | 
|  | 131 | /sys/devices/system/memory/memoryXXX | 
|  | 132 | (XXX is section id.) | 
|  | 133 |  | 
|  | 134 | Now, XXX is defined as start_address_of_section / section_size. | 
|  | 135 |  | 
|  | 136 | For example, assume 1GiB section size. A device for a memory starting at | 
|  | 137 | 0x100000000 is /sys/device/system/memory/memory4 | 
|  | 138 | (0x100000000 / 1Gib = 4) | 
|  | 139 | This device covers address range [0x100000000 ... 0x140000000) | 
|  | 140 |  | 
| Gary Hade | c04fc58 | 2009-01-06 14:39:14 -0800 | [diff] [blame] | 141 | Under each section, you can see 4 files. | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 142 |  | 
|  | 143 | /sys/devices/system/memory/memoryXXX/phys_index | 
|  | 144 | /sys/devices/system/memory/memoryXXX/phys_device | 
|  | 145 | /sys/devices/system/memory/memoryXXX/state | 
| Gary Hade | c04fc58 | 2009-01-06 14:39:14 -0800 | [diff] [blame] | 146 | /sys/devices/system/memory/memoryXXX/removable | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 147 |  | 
|  | 148 | 'phys_index' : read-only and contains section id, same as XXX. | 
|  | 149 | 'state'      : read-write | 
|  | 150 | at read:  contains online/offline state of memory. | 
|  | 151 | at write: user can specify "online", "offline" command | 
|  | 152 | 'phys_device': read-only: designed to show the name of physical memory device. | 
|  | 153 | This is not well implemented now. | 
| Gary Hade | c04fc58 | 2009-01-06 14:39:14 -0800 | [diff] [blame] | 154 | 'removable'  : read-only: contains an integer value indicating | 
|  | 155 | whether the memory section is removable or not | 
|  | 156 | removable.  A value of 1 indicates that the memory | 
|  | 157 | section is removable and a value of 0 indicates that | 
|  | 158 | it is not removable. | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 159 |  | 
|  | 160 | NOTE: | 
|  | 161 | These directories/files appear after physical memory hotplug phase. | 
|  | 162 |  | 
| Alex Chiang | dee5d0d | 2009-12-14 17:59:05 -0800 | [diff] [blame] | 163 | If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed | 
|  | 164 | via symbolic links located in the /sys/devices/system/node/node* directories. | 
|  | 165 |  | 
|  | 166 | For example: | 
| Gary Hade | c04fc58 | 2009-01-06 14:39:14 -0800 | [diff] [blame] | 167 | /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 168 |  | 
| Alex Chiang | dee5d0d | 2009-12-14 17:59:05 -0800 | [diff] [blame] | 169 | A backlink will also be created: | 
|  | 170 | /sys/devices/system/memory/memory9/node0 -> ../../node/node0 | 
|  | 171 |  | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 172 | -------------------------------- | 
|  | 173 | 4. Physical memory hot-add phase | 
|  | 174 | -------------------------------- | 
|  | 175 |  | 
|  | 176 | 4.1 Hardware(Firmware) Support | 
|  | 177 | ------------ | 
|  | 178 | On x86_64/ia64 platform, memory hotplug by ACPI is supported. | 
|  | 179 |  | 
|  | 180 | In general, the firmware (ACPI) which supports memory hotplug defines | 
|  | 181 | memory class object of _HID "PNP0C80". When a notify is asserted to PNP0C80, | 
|  | 182 | Linux's ACPI handler does hot-add memory to the system and calls a hotplug udev | 
|  | 183 | script. This will be done automatically. | 
|  | 184 |  | 
|  | 185 | But scripts for memory hotplug are not contained in generic udev package(now). | 
|  | 186 | You may have to write it by yourself or online/offline memory by hand. | 
|  | 187 | Please see "How to online memory", "How to offline memory" in this text. | 
|  | 188 |  | 
|  | 189 | If firmware supports NUMA-node hotplug, and defines an object _HID "ACPI0004", | 
|  | 190 | "PNP0A05", or "PNP0A06", notification is asserted to it, and ACPI handler | 
|  | 191 | calls hotplug code for all of objects which are defined in it. | 
|  | 192 | If memory device is found, memory hotplug code will be called. | 
|  | 193 |  | 
|  | 194 |  | 
|  | 195 | 4.2 Notify memory hot-add event by hand | 
|  | 196 | ------------ | 
|  | 197 | In some environments, especially virtualized environment, firmware will not | 
|  | 198 | notify memory hotplug event to the kernel. For such environment, "probe" | 
|  | 199 | interface is supported. This interface depends on CONFIG_ARCH_MEMORY_PROBE. | 
|  | 200 |  | 
|  | 201 | Now, CONFIG_ARCH_MEMORY_PROBE is supported only by powerpc but it does not | 
|  | 202 | contain highly architecture codes. Please add config if you need "probe" | 
|  | 203 | interface. | 
|  | 204 |  | 
|  | 205 | Probe interface is located at | 
|  | 206 | /sys/devices/system/memory/probe | 
|  | 207 |  | 
|  | 208 | You can tell the physical address of new memory to the kernel by | 
|  | 209 |  | 
|  | 210 | % echo start_address_of_new_memory > /sys/devices/system/memory/probe | 
|  | 211 |  | 
|  | 212 | Then, [start_address_of_new_memory, start_address_of_new_memory + section_size) | 
|  | 213 | memory range is hot-added. In this case, hotplug script is not called (in | 
|  | 214 | current implementation). You'll have to online memory by yourself. | 
|  | 215 | Please see "How to online memory" in this text. | 
|  | 216 |  | 
|  | 217 |  | 
|  | 218 |  | 
|  | 219 | ------------------------------ | 
|  | 220 | 5. Logical Memory hot-add phase | 
|  | 221 | ------------------------------ | 
|  | 222 |  | 
|  | 223 | 5.1. State of memory | 
|  | 224 | ------------ | 
|  | 225 | To see (online/offline) state of memory section, read 'state' file. | 
|  | 226 |  | 
|  | 227 | % cat /sys/device/system/memory/memoryXXX/state | 
|  | 228 |  | 
|  | 229 |  | 
|  | 230 | If the memory section is online, you'll read "online". | 
|  | 231 | If the memory section is offline, you'll read "offline". | 
|  | 232 |  | 
|  | 233 |  | 
|  | 234 | 5.2. How to online memory | 
|  | 235 | ------------ | 
|  | 236 | Even if the memory is hot-added, it is not at ready-to-use state. | 
|  | 237 | For using newly added memory, you have to "online" the memory section. | 
|  | 238 |  | 
|  | 239 | For onlining, you have to write "online" to the section's state file as: | 
|  | 240 |  | 
|  | 241 | % echo online > /sys/devices/system/memory/memoryXXX/state | 
|  | 242 |  | 
|  | 243 | After this, section memoryXXX's state will be 'online' and the amount of | 
|  | 244 | available memory will be increased. | 
|  | 245 |  | 
|  | 246 | Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA). | 
|  | 247 | This may be changed in future. | 
|  | 248 |  | 
|  | 249 |  | 
|  | 250 |  | 
|  | 251 | ------------------------ | 
|  | 252 | 6. Logical memory remove | 
|  | 253 | ------------------------ | 
|  | 254 |  | 
|  | 255 | 6.1 Memory offline and ZONE_MOVABLE | 
|  | 256 | ------------ | 
|  | 257 | Memory offlining is more complicated than memory online. Because memory offline | 
|  | 258 | has to make the whole memory section be unused, memory offline can fail if | 
|  | 259 | the section includes memory which cannot be freed. | 
|  | 260 |  | 
|  | 261 | In general, memory offline can use 2 techniques. | 
|  | 262 |  | 
|  | 263 | (1) reclaim and free all memory in the section. | 
|  | 264 | (2) migrate all pages in the section. | 
|  | 265 |  | 
|  | 266 | In the current implementation, Linux's memory offline uses method (2), freeing | 
|  | 267 | all  pages in the section by page migration. But not all pages are | 
|  | 268 | migratable. Under current Linux, migratable pages are anonymous pages and | 
|  | 269 | page caches. For offlining a section by migration, the kernel has to guarantee | 
|  | 270 | that the section contains only migratable pages. | 
|  | 271 |  | 
|  | 272 | Now, a boot option for making a section which consists of migratable pages is | 
|  | 273 | supported. By specifying "kernelcore=" or "movablecore=" boot option, you can | 
|  | 274 | create ZONE_MOVABLE...a zone which is just used for movable pages. | 
|  | 275 | (See also Documentation/kernel-parameters.txt) | 
|  | 276 |  | 
|  | 277 | Assume the system has "TOTAL" amount of memory at boot time, this boot option | 
|  | 278 | creates ZONE_MOVABLE as following. | 
|  | 279 |  | 
|  | 280 | 1) When kernelcore=YYYY boot option is used, | 
|  | 281 | Size of memory not for movable pages (not for offline) is YYYY. | 
|  | 282 | Size of memory for movable pages (for offline) is TOTAL-YYYY. | 
|  | 283 |  | 
|  | 284 | 2) When movablecore=ZZZZ boot option is used, | 
|  | 285 | Size of memory not for movable pages (not for offline) is TOTAL - ZZZZ. | 
|  | 286 | Size of memory for movable pages (for offline) is ZZZZ. | 
|  | 287 |  | 
|  | 288 |  | 
|  | 289 | Note) Unfortunately, there is no information to show which section belongs | 
|  | 290 | to ZONE_MOVABLE. This is TBD. | 
|  | 291 |  | 
|  | 292 |  | 
|  | 293 | 6.2. How to offline memory | 
|  | 294 | ------------ | 
|  | 295 | You can offline a section by using the same sysfs interface that was used in | 
|  | 296 | memory onlining. | 
|  | 297 |  | 
|  | 298 | % echo offline > /sys/devices/system/memory/memoryXXX/state | 
|  | 299 |  | 
|  | 300 | If offline succeeds, the state of the memory section is changed to be "offline". | 
|  | 301 | If it fails, some error core (like -EBUSY) will be returned by the kernel. | 
|  | 302 | Even if a section does not belong to ZONE_MOVABLE, you can try to offline it. | 
|  | 303 | If it doesn't contain 'unmovable' memory, you'll get success. | 
|  | 304 |  | 
|  | 305 | A section under ZONE_MOVABLE is considered to be able to be offlined easily. | 
|  | 306 | But under some busy state, it may return -EBUSY. Even if a memory section | 
|  | 307 | cannot be offlined due to -EBUSY, you can retry offlining it and may be able to | 
|  | 308 | offline it (or not). | 
|  | 309 | (For example, a page is referred to by some kernel internal call and released | 
|  | 310 | soon.) | 
|  | 311 |  | 
|  | 312 | Consideration: | 
|  | 313 | Memory hotplug's design direction is to make the possibility of memory offlining | 
|  | 314 | higher and to guarantee unplugging memory under any situation. But it needs | 
|  | 315 | more work. Returning -EBUSY under some situation may be good because the user | 
|  | 316 | can decide to retry more or not by himself. Currently, memory offlining code | 
|  | 317 | does some amount of retry with 120 seconds timeout. | 
|  | 318 |  | 
|  | 319 | ------------------------- | 
|  | 320 | 7. Physical memory remove | 
|  | 321 | ------------------------- | 
|  | 322 | Need more implementation yet.... | 
|  | 323 | - Notification completion of remove works by OS to firmware. | 
|  | 324 | - Guard from remove if not yet. | 
|  | 325 |  | 
| Yasunori Goto | 10020ca | 2007-10-21 16:41:36 -0700 | [diff] [blame] | 326 | -------------------------------- | 
|  | 327 | 8. Memory hotplug event notifier | 
|  | 328 | -------------------------------- | 
|  | 329 | Memory hotplug has event notifer. There are 6 types of notification. | 
|  | 330 |  | 
|  | 331 | MEMORY_GOING_ONLINE | 
|  | 332 | Generated before new memory becomes available in order to be able to | 
|  | 333 | prepare subsystems to handle memory. The page allocator is still unable | 
|  | 334 | to allocate from the new memory. | 
|  | 335 |  | 
|  | 336 | MEMORY_CANCEL_ONLINE | 
|  | 337 | Generated if MEMORY_GOING_ONLINE fails. | 
|  | 338 |  | 
|  | 339 | MEMORY_ONLINE | 
| Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 340 | Generated when memory has successfully brought online. The callback may | 
| Yasunori Goto | 10020ca | 2007-10-21 16:41:36 -0700 | [diff] [blame] | 341 | allocate pages from the new memory. | 
|  | 342 |  | 
|  | 343 | MEMORY_GOING_OFFLINE | 
|  | 344 | Generated to begin the process of offlining memory. Allocations are no | 
|  | 345 | longer possible from the memory but some of the memory to be offlined | 
|  | 346 | is still in use. The callback can be used to free memory known to a | 
|  | 347 | subsystem from the indicated memory section. | 
|  | 348 |  | 
|  | 349 | MEMORY_CANCEL_OFFLINE | 
|  | 350 | Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from | 
|  | 351 | the section that we attempted to offline. | 
|  | 352 |  | 
|  | 353 | MEMORY_OFFLINE | 
|  | 354 | Generated after offlining memory is complete. | 
|  | 355 |  | 
|  | 356 | A callback routine can be registered by | 
|  | 357 | hotplug_memory_notifier(callback_func, priority) | 
|  | 358 |  | 
|  | 359 | The second argument of callback function (action) is event types of above. | 
|  | 360 | The third argument is passed by pointer of struct memory_notify. | 
|  | 361 |  | 
|  | 362 | struct memory_notify { | 
|  | 363 | unsigned long start_pfn; | 
|  | 364 | unsigned long nr_pages; | 
| Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 365 | int status_change_nid; | 
| Yasunori Goto | 10020ca | 2007-10-21 16:41:36 -0700 | [diff] [blame] | 366 | } | 
|  | 367 |  | 
|  | 368 | start_pfn is start_pfn of online/offline memory. | 
|  | 369 | nr_pages is # of pages of online/offline memory. | 
|  | 370 | status_change_nid is set node id when N_HIGH_MEMORY of nodemask is (will be) | 
|  | 371 | set/clear. It means a new(memoryless) node gets new memory by online and a | 
|  | 372 | node loses all memory. If this is -1, then nodemask status is not changed. | 
|  | 373 | If status_changed_nid >= 0, callback should create/discard structures for the | 
|  | 374 | node if necessary. | 
|  | 375 |  | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 376 | -------------- | 
| Yasunori Goto | 10020ca | 2007-10-21 16:41:36 -0700 | [diff] [blame] | 377 | 9. Future Work | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 378 | -------------- | 
|  | 379 | - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like | 
|  | 380 | sysctl or new control file. | 
|  | 381 | - showing memory section and physical device relationship. | 
| Yasunori Goto | 6867c93 | 2007-08-10 13:00:59 -0700 | [diff] [blame] | 382 | - showing memory section is under ZONE_MOVABLE or not | 
|  | 383 | - test and make it better memory offlining. | 
|  | 384 | - support HugeTLB page migration and offlining. | 
|  | 385 | - memmap removing at memory offline. | 
|  | 386 | - physical remove memory. | 
|  | 387 |  |