path: root/Documentation/memory-hotplug.txt
AgeCommit message (Collapse)Author
2012-12-12hotplug: update nodemasks managementLai Jiangshan
Update nodemasks management for N_MEMORY. [ fix build] Signed-off-by: Lai Jiangshan <> Signed-off-by: Wen Congyang <> Cc: Christoph Lameter <> Cc: Hillf Danton <> Cc: Lin Feng <> Cc: David Rientjes <> Signed-off-by: Bob Liu <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2012-12-11mm, memory-hotplug: dynamic configure movable memory and portion memoryLai Jiangshan
Add online_movable and online_kernel for logic memory hotplug. This is the dynamic version of "movablecore" & "kernelcore". We have the same reason to introduce it as to introduce "movablecore" & "kernelcore". It has the same motive as "movablecore" & "kernelcore", but it is dynamic/running-time: o We can configure memory as kernelcore or movablecore after boot. Userspace workload is increased, we need more hugepage, we can't use "online_movable" to add memory and allow the system use more THP(transparent-huge-page), vice-verse when kernel workload is increase. Also help for virtualization to dynamic configure host/guest's memory, to save/(reduce waste) memory. Memory capacity on Demand o When a new node is physically online after boot, we need to use "online_movable" or "online_kernel" to configure/portion it as we expected when we logic-online it. This configuration also helps for physically-memory-migrate. o all benefit as the same as existed "movablecore" & "kernelcore". o Preparing for movable-node, which is very important for power-saving, hardware partitioning and high-available-system(hardware fault management). (Note, we don't introduce movable-node here.) Action behavior: When a memoryblock/memorysection is onlined by "online_movable", the kernel will not have directly reference to the page of the memoryblock, thus we can remove that memory any time when needed. When it is online by "online_kernel", the kernel can use it. When it is online by "online", the zone type doesn't changed. Current constraints: Only the memoryblock which is adjacent to the ZONE_MOVABLE can be online from ZONE_NORMAL to ZONE_MOVABLE. [ use min_t, cleanups] Signed-off-by: Lai Jiangshan <> Signed-off-by: Wen Congyang <> Cc: Yasuaki Ishimatsu <> Cc: Lai Jiangshan <> Cc: Jiang Liu <> Cc: KOSAKI Motohiro <> Cc: Minchan Kim <> Cc: Mel Gorman <> Cc: David Rientjes <> Cc: Yinghai Lu <> Cc: Rusty Russell <> Cc: Greg KH <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2012-12-11memory_hotplug: fix possible incorrect node_states[N_NORMAL_MEMORY]Lai Jiangshan
Currently memory_hotplug only manages the node_states[N_HIGH_MEMORY], it forgets to manage node_states[N_NORMAL_MEMORY]. This may cause node_states[N_NORMAL_MEMORY] to become incorrect. Example, if a node is empty before online, and we online a memory which is in ZONE_NORMAL. And after online, node_states[N_HIGH_MEMORY] is correct, but node_states[N_NORMAL_MEMORY] is incorrect, the online code doesn't set the new online node to node_states[N_NORMAL_MEMORY]. The same thing will happen when offlining (the offline code doesn't clear the node from node_states[N_NORMAL_MEMORY] when needed). Some memory managment code depends node_states[N_NORMAL_MEMORY], so we have to fix up the node_states[N_NORMAL_MEMORY]. We add node_states_check_changes_online() and node_states_check_changes_offline() to detect whether node_states[N_HIGH_MEMORY] and node_states[N_NORMAL_MEMORY] are changed while hotpluging. Also add @status_change_nid_normal to struct memory_notify, thus the memory hotplug callbacks know whether the node_states[N_NORMAL_MEMORY] are changed. (We can add a @flags and reuse @status_change_nid instead of introducing @status_change_nid_normal, but it will add much more complexity in memory hotplug callback in every subsystem. So introducing @status_change_nid_normal is better and it doesn't change the sematics of @status_change_nid) Signed-off-by: Lai Jiangshan <> Cc: David Rientjes <> Cc: Minchan Kim <> Cc: KOSAKI Motohiro <> Cc: Yasuaki Ishimatsu <> Cc: Rob Landley <> Cc: Jiang Liu <> Cc: Kay Sievers <> Cc: Greg Kroah-Hartman <> Cc: Mel Gorman <> Cc: Wen Congyang <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2012-04-16Documentation: Fix typo in multiple files in DocumentationMasanari Iida
Correct multiple spelling typo in Documentation. Signed-off-by: Masanari Iida <> Acked-by: Rob Landley <> Reported-by: Anders Larsen <> Signed-off-by: Jiri Kosina <>
2011-02-03memory hotplug: Allow memory blocks to span multiple memory sectionsNathan Fontenot
Update the memory sysfs code such that each sysfs memory directory is now considered a memory block that can span multiple memory sections per memory block. The default size of each memory block is SECTION_SIZE_BITS to maintain the current behavior of having a single memory section per memory block (i.e. one sysfs directory per memory section). For architectures that want to have memory blocks span multiple memory sections they need only define their own memory_block_size_bytes() routine. Update the memory hotplug documentation to reflect the new behaviors of memory blocks reflected in sysfs. Signed-off-by: Nathan Fontenot <> Reviewed-by: Robin Holt <> Reviewed-by: KAMEZAWA Hiroyuki <> Signed-off-by: Greg Kroah-Hartman <>
2009-12-15mm: add numa node symlink for memory section in sysfsAlex Chiang
Commit c04fc586c (mm: show node to memory section relationship with symlinks in sysfs) created symlinks from nodes to memory sections, e.g. /sys/devices/system/node/node1/memory135 -> ../../memory/memory135 If you're examining the memory section though and are wondering what node it might belong to, you can find it by grovelling around in sysfs, but it's a little cumbersome. Add a reverse symlink for each memory section that points back to the node to which it belongs. Signed-off-by: Alex Chiang <> Cc: Gary Hade <> Cc: Badari Pulavarty <> Cc: Ingo Molnar <> Acked-by: David Rientjes <> Cc: Greg KH <> Cc: Randy Dunlap <> Cc: David Rientjes <> Cc: KOSAKI Motohiro <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2009-06-12trivial: Miscellaneous documentation typo fixesMatt LaPlante
Fix various typos in documentation txts. Signed-off-by: Matt LaPlante <> Signed-off-by: Jiri Kosina <>
2009-01-06mm: show node to memory section relationship with symlinks in sysfsGary Hade
Show node to memory section relationship with symlinks in sysfs Add /sys/devices/system/node/nodeX/memoryY symlinks for all the memory sections located on nodeX. For example: /sys/devices/system/node/node1/memory135 -> ../../memory/memory135 indicates that memory section 135 resides on node1. Also revises documentation to cover this change as well as updating Documentation/ABI/testing/sysfs-devices-memory to include descriptions of memory hotremove files 'phys_device', 'phys_index', and 'state' that were previously not described there. In addition to it always being a good policy to provide users with the maximum possible amount of physical location information for resources that can be hot-added and/or hot-removed, the following are some (but likely not all) of the user benefits provided by this change. Immediate: - Provides information needed to determine the specific node on which a defective DIMM is located. This will reduce system downtime when the node or defective DIMM is swapped out. - Prevents unintended onlining of a memory section that was previously offlined due to a defective DIMM. This could happen during node hot-add when the user or node hot-add assist script onlines _all_ offlined sections due to user or script inability to identify the specific memory sections located on the hot-added node. The consequences of reintroducing the defective memory could be ugly. - Provides information needed to vary the amount and distribution of memory on specific nodes for testing or debugging purposes. Future: - Will provide information needed to identify the memory sections that need to be offlined prior to physical removal of a specific node. Symlink creation during boot was tested on 2-node x86_64, 2-node ppc64, and 2-node ia64 systems. Symlink creation during physical memory hot-add tested on a 2-node x86_64 system. Signed-off-by: Gary Hade <> Signed-off-by: Badari Pulavarty <> Acked-by: Ingo Molnar <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2007-10-22memory hotplug: document the memory hotplug notifierYasunori Goto
Add description about event notification callback routine to the document Signed-off-by: Yasunori Goto <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2007-08-11Memory hotplug documentYasunori Goto
This is add a document for memory hotplug to describe "How to use" and "Current status". Signed-off-by: KAMEZAWA Hiroyuki <> Signed-off-by: Yasunori Goto <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>