| Message ID | 20190527111152.16324-1-david@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm/memory_hotplug: Factor out memory block devicehandling | expand |
IMHO, there is some typo. s/devicehandling/device handling/ On Mon, May 27, 2019 at 01:11:41PM +0200, David Hildenbrand wrote: >We only want memory block devices for memory to be onlined/offlined >(add/remove from the buddy). This is required so user space can >online/offline memory and kdump gets notified about newly onlined memory. > >Let's factor out creation/removal of memory block devices. This helps >to further cleanup arch_add_memory/arch_remove_memory() and to make >implementation of new features easier - especially sub-section >memory hot add from Dan. > >Anshuman Khandual is currently working on arch_remove_memory(). I added >a temporary solution via "arm64/mm: Add temporary arch_remove_memory() >implementation", that is sufficient as a firsts tep in the context of s/firsts tep/first step/ >this series. (we don't cleanup page tables in case anything goes >wrong already) > >Did a quick sanity test with DIMM plug/unplug, making sure all devices >and sysfs links properly get added/removed. Compile tested on s390x and >x86-64. > >Based on next/master. > >Next refactoring on my list will be making sure that remove_memory() >will never deal with zones / access "struct pages". Any kind of zone >handling will have to be done when offlining system memory / before >removing device memory. I am thinking about remove_pfn_range_from_zone()", >du undo everything "move_pfn_range_to_zone()" did. what is "du undo"? I may not get it. > >v2 -> v3: >- Add "s390x/mm: Fail when an altmap is used for arch_add_memory()" >- Add "arm64/mm: Add temporary arch_remove_memory() implementation" >- Add "drivers/base/memory: Pass a block_id to init_memory_block()" >- Various changes to "mm/memory_hotplug: Create memory block devices > after arch_add_memory()" and "mm/memory_hotplug: Create memory block > devices after arch_add_memory()" due to switching from sections to > block_id's. > >v1 -> v2: >- s390x/mm: Implement arch_remove_memory() >-- remove mapping after "__remove_pages" > >David Hildenbrand (11): > mm/memory_hotplug: Simplify and fix check_hotplug_memory_range() > s390x/mm: Fail when an altmap is used for arch_add_memory() > s390x/mm: Implement arch_remove_memory() > arm64/mm: Add temporary arch_remove_memory() implementation > drivers/base/memory: Pass a block_id to init_memory_block() > mm/memory_hotplug: Allow arch_remove_pages() without > CONFIG_MEMORY_HOTREMOVE > mm/memory_hotplug: Create memory block devices after arch_add_memory() > mm/memory_hotplug: Drop MHP_MEMBLOCK_API > mm/memory_hotplug: Remove memory block devices before > arch_remove_memory() > mm/memory_hotplug: Make unregister_memory_block_under_nodes() never > fail > mm/memory_hotplug: Remove "zone" parameter from > sparse_remove_one_section > > arch/arm64/mm/mmu.c | 17 +++++ > arch/ia64/mm/init.c | 2 - > arch/powerpc/mm/mem.c | 2 - > arch/s390/mm/init.c | 18 +++-- > arch/sh/mm/init.c | 2 - > arch/x86/mm/init_32.c | 2 - > arch/x86/mm/init_64.c | 2 - > drivers/base/memory.c | 134 +++++++++++++++++++-------------- > drivers/base/node.c | 27 +++---- > include/linux/memory.h | 6 +- > include/linux/memory_hotplug.h | 12 +-- > include/linux/node.h | 7 +- > mm/memory_hotplug.c | 44 +++++------ > mm/sparse.c | 10 +-- > 14 files changed, 140 insertions(+), 145 deletions(-) > >-- >2.20.1
On 03.06.19 23:21, Wei Yang wrote: > IMHO, there is some typo. Yes, thanks. > > s/devicehandling/device handling/ > > On Mon, May 27, 2019 at 01:11:41PM +0200, David Hildenbrand wrote: >> We only want memory block devices for memory to be onlined/offlined >> (add/remove from the buddy). This is required so user space can >> online/offline memory and kdump gets notified about newly onlined memory. >> >> Let's factor out creation/removal of memory block devices. This helps >> to further cleanup arch_add_memory/arch_remove_memory() and to make >> implementation of new features easier - especially sub-section >> memory hot add from Dan. >> >> Anshuman Khandual is currently working on arch_remove_memory(). I added >> a temporary solution via "arm64/mm: Add temporary arch_remove_memory() >> implementation", that is sufficient as a firsts tep in the context of > > s/firsts tep/first step/ > >> this series. (we don't cleanup page tables in case anything goes >> wrong already) >> >> Did a quick sanity test with DIMM plug/unplug, making sure all devices >> and sysfs links properly get added/removed. Compile tested on s390x and >> x86-64. >> >> Based on next/master. >> >> Next refactoring on my list will be making sure that remove_memory() >> will never deal with zones / access "struct pages". Any kind of zone >> handling will have to be done when offlining system memory / before >> removing device memory. I am thinking about remove_pfn_range_from_zone()", >> du undo everything "move_pfn_range_to_zone()" did. > > what is "du undo"? I may not get it. to undo ;)
We only want memory block devices for memory to be onlined/offlined (add/remove from the buddy). This is required so user space can online/offline memory and kdump gets notified about newly onlined memory. Let's factor out creation/removal of memory block devices. This helps to further cleanup arch_add_memory/arch_remove_memory() and to make implementation of new features easier - especially sub-section memory hot add from Dan. Anshuman Khandual is currently working on arch_remove_memory(). I added a temporary solution via "arm64/mm: Add temporary arch_remove_memory() implementation", that is sufficient as a firsts tep in the context of this series. (we don't cleanup page tables in case anything goes wrong already) Did a quick sanity test with DIMM plug/unplug, making sure all devices and sysfs links properly get added/removed. Compile tested on s390x and x86-64. Based on next/master. Next refactoring on my list will be making sure that remove_memory() will never deal with zones / access "struct pages". Any kind of zone handling will have to be done when offlining system memory / before removing device memory. I am thinking about remove_pfn_range_from_zone()", du undo everything "move_pfn_range_to_zone()" did. v2 -> v3: - Add "s390x/mm: Fail when an altmap is used for arch_add_memory()" - Add "arm64/mm: Add temporary arch_remove_memory() implementation" - Add "drivers/base/memory: Pass a block_id to init_memory_block()" - Various changes to "mm/memory_hotplug: Create memory block devices after arch_add_memory()" and "mm/memory_hotplug: Create memory block devices after arch_add_memory()" due to switching from sections to block_id's. v1 -> v2: - s390x/mm: Implement arch_remove_memory() -- remove mapping after "__remove_pages" David Hildenbrand (11): mm/memory_hotplug: Simplify and fix check_hotplug_memory_range() s390x/mm: Fail when an altmap is used for arch_add_memory() s390x/mm: Implement arch_remove_memory() arm64/mm: Add temporary arch_remove_memory() implementation drivers/base/memory: Pass a block_id to init_memory_block() mm/memory_hotplug: Allow arch_remove_pages() without CONFIG_MEMORY_HOTREMOVE mm/memory_hotplug: Create memory block devices after arch_add_memory() mm/memory_hotplug: Drop MHP_MEMBLOCK_API mm/memory_hotplug: Remove memory block devices before arch_remove_memory() mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail mm/memory_hotplug: Remove "zone" parameter from sparse_remove_one_section arch/arm64/mm/mmu.c | 17 +++++ arch/ia64/mm/init.c | 2 - arch/powerpc/mm/mem.c | 2 - arch/s390/mm/init.c | 18 +++-- arch/sh/mm/init.c | 2 - arch/x86/mm/init_32.c | 2 - arch/x86/mm/init_64.c | 2 - drivers/base/memory.c | 134 +++++++++++++++++++-------------- drivers/base/node.c | 27 +++---- include/linux/memory.h | 6 +- include/linux/memory_hotplug.h | 12 +-- include/linux/node.h | 7 +- mm/memory_hotplug.c | 44 +++++------ mm/sparse.c | 10 +-- 14 files changed, 140 insertions(+), 145 deletions(-)