Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
On 07/11/2012 08:54 AM, Yasuaki Ishimatsu wrote: Hi Jiang, 2012/07/11 9:21, Jiang Liu wrote: On 07/11/2012 08:09 AM, Yasuaki Ishimatsu wrote: Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. We have modified the ZONE_MOVABLE spreading and bootmem allocation. If the kernelcore or movablecore kernel parameters are present, we follow current behavior. If those parameter are absent and the platform supports physical hotplug, we will concentrate DMA/NORMAL memory to specific nodes. That's interesting. I want to know more details, if you do not mind. Current kernel doesn't do the behavior, does it? So I think you have some patches for changing the behavior. Will you merge these patches into community kernel? Yeah, we do have patches for that. But it's still prototype, still much work needed before sending them to the community. Currently I'm trying to send out patches for an ACPI based system device hotplug framework, which will support processor, memory, IOH and node hotplug in a unified way. After that, I will prepare the memory hotplug code. Thanks! Gerry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
On 07/11/2012 08:09 AM, Yasuaki Ishimatsu wrote: Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. We have modified the ZONE_MOVABLE spreading and bootmem allocation. If the kernelcore or movablecore kernel parameters are present, we follow current behavior. If those parameter are absent and the platform supports physical hotplug, we will concentrate DMA/NORMAL memory to specific nodes. Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
Hi Jiang, 2012/07/11 9:21, Jiang Liu wrote: On 07/11/2012 08:09 AM, Yasuaki Ishimatsu wrote: Hi Jiang, 2012/07/11 1:50, Jiang Liu wrote: On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote: Hi Christoph, 2012/07/10 0:18, Christoph Lameter wrote: On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? We plan to release a dynamic hardware partitionable system. It will be able to hot remove/add a system board which included memory and cpu. But as you know, Linux does not support memory hot-remove on x86 box. So I try to develop it. Current plan to hot remove system board is to use container driver. Thus I define the system board in ACPI DSDT table as a container device. It have supported hot-add a container device. And if container device has _EJ0 ACPI method, eject file to remove the container device is prepared as follow: # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject --w---. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject When I hot-remove the container device, I echo 1 to the file as follow: #echo 1 /sys/bus/acpi/devices/ACPI0004\:02/eject Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove() for removing memory device. But the code does not do nothing. So I developed the continuation of the function. You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I know it. So my memory hot-remove plan is as follows: 1. hot-added a system board All memory which included the system board is offline. 2. online the memory as removable page The function has not supported yet. It is being developed by Lai as follow: http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html If it is supported, I will be able to create movable memory. 3. hot-remove the memory by container device's eject file We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug for Itanium and is now porting it to x86. But with currently solution, memory hotplug functionality may cause 10-20% performance decrease because we concentrate all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only hosts ZONE_MOVABLE. We are working on solution to minimize the performance drop now. Thank you for your interesting response. I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE? To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore. But it is not enough, since the requested amount is spread evenly throughout all nodes in the system. So I think we do not have way to move all other NUMA node to ZONE_MOVABLE. We have modified the ZONE_MOVABLE spreading and bootmem allocation. If the kernelcore or movablecore kernel parameters are present, we follow current behavior. If those parameter are absent and the platform supports physical hotplug, we will concentrate DMA/NORMAL memory to specific nodes. That's interesting. I want to know more details, if you do not mind. Current kernel doesn't do the behavior, does it? So I think you have some patches for changing the behavior. Will you merge these patches into community kernel? Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu Thanks, Yasuaki Ishimatsu I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
At 07/09/2012 06:21 PM, Yasuaki Ishimatsu Wrote:
This patch series aims to support physical memory hot-remove.
[RFC PATCH v3 1/13] memory-hotplug : rename remove_memory to offline_memory
[RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to
acpi_memory_device_remove
[RFC PATCH v3 3/13] memory-hotplug : unify argument of
firmware_map_add_early/hotplug
[RFC PATCH v3 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
[RFC PATCH v3 5/13] memory-hotplug : does not release memory region in
PAGES_PER_SECTION chunks
[RFC PATCH v3 6/13] memory-hotplug : add memory_block_release
[RFC PATCH v3 7/13] memory-hotplug : remove_memory calls __remove_pages
[RFC PATCH v3 8/13] memory-hotplug : check page type in get_page_bootmem
[RFC PATCH v3 9/13] memory-hotplug : move register_page_bootmem_info_node
and put_page_bootmem for
sparse-vmemmap
[RFC PATCH v3 10/13] memory-hotplug : implement
register_page_bootmem_info_section of sparse-vmemmap
[RFC PATCH v3 11/13] memory-hotplug : free memmap of sparse-vmemmap
[RFC PATCH v3 12/13] memory-hotplug : add node_device_release
[RFC PATCH v3 13/13] memory-hotplug : remove sysfs file of node
Even if you apply these patches, you cannot remove the physical memory
completely since these patches are still under development. I want you to
cooperate to improve the physical memory hot-remove. So please review these
patches and give your comment/idea.
The patches can free/remove following things:
- acpi_memory_info : [RFC PATCH 2/13]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 4/13]
- iomem_resource: [RFC PATCH 5/13]
- mem_section and related sysfs files : [RFC PATCH 6-11/13]
- node and related sysfs files : [RFC PATCH 12-13/13]
The patches cannot do following things yet:
- page table of removed memory
If you find lack of function for physical memory hot-remove, please let me
know.
change log of v3:
* rebase to 3.5.0-rc6
[RFC PATCH v2 2/13]
* remove extra kobject_put()
* The patch was commented by Wen. Wen's comment is
acpi_memory_device_remove() should ignore a return value of
remove_memory() since caller does not care the return value.
But I did not change it since I think caller should care the
return value. And I am trying to fix it as follow:
https://lkml.org/lkml/2012/7/5/624
acpi_memory_device_remove() will be called not only when we write
1 to /sys/bus/acpi/devices/PNP0C80:XX/eject. When we unbind it
from the driver or remove the module acpi_memhotplug, this function
will be called too.
I will check whether your patch can work for these two cases.
Thanks
Wen Congyang
[RFC PATCH v2 4/13]
* remove a firmware_memmap_entry allocated by kzmalloc()
change log of v2:
[RFC PATCH v2 2/13]
* check whether memory block is offline or not before calling
offline_memory()
* check whether section is valid or not in is_memblk_offline()
* call kobject_put() for each memory_block in is_memblk_offline()
[RFC PATCH v2 3/13]
* unify the end argument of firmware_map_add_early/hotplug
[RFC PATCH v2 4/13]
* add release_firmware_map_entry() for freeing firmware_map_entry
[RFC PATCH v2 6/13]
* add release_memory_block() for freeing memory_block
[RFC PATCH v2 11/13]
* fix wrong arguments of free_pages()
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 16 +-
arch/x86/mm/init_64.c | 144
drivers/acpi/acpi_memhotplug.c | 28
drivers/base/memory.c | 54 -
drivers/base/node.c |7 +
drivers/firmware/memmap.c | 78 -
include/linux/firmware-map.h|6 +
include/linux/memory.h |5
include/linux/memory_hotplug.h | 17 --
include/linux/mm.h |5
mm/memory_hotplug.c | 98
mm/sparse.c |5
12 files changed, 414 insertions(+), 49 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
At 07/11/2012 09:52 AM, Wen Congyang Wrote:
At 07/09/2012 06:21 PM, Yasuaki Ishimatsu Wrote:
This patch series aims to support physical memory hot-remove.
[RFC PATCH v3 1/13] memory-hotplug : rename remove_memory to offline_memory
[RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to
acpi_memory_device_remove
[RFC PATCH v3 3/13] memory-hotplug : unify argument of
firmware_map_add_early/hotplug
[RFC PATCH v3 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
[RFC PATCH v3 5/13] memory-hotplug : does not release memory region in
PAGES_PER_SECTION chunks
[RFC PATCH v3 6/13] memory-hotplug : add memory_block_release
[RFC PATCH v3 7/13] memory-hotplug : remove_memory calls __remove_pages
[RFC PATCH v3 8/13] memory-hotplug : check page type in get_page_bootmem
[RFC PATCH v3 9/13] memory-hotplug : move register_page_bootmem_info_node
and put_page_bootmem for
sparse-vmemmap
[RFC PATCH v3 10/13] memory-hotplug : implement
register_page_bootmem_info_section of sparse-vmemmap
[RFC PATCH v3 11/13] memory-hotplug : free memmap of sparse-vmemmap
[RFC PATCH v3 12/13] memory-hotplug : add node_device_release
[RFC PATCH v3 13/13] memory-hotplug : remove sysfs file of node
Even if you apply these patches, you cannot remove the physical memory
completely since these patches are still under development. I want you to
cooperate to improve the physical memory hot-remove. So please review these
patches and give your comment/idea.
The patches can free/remove following things:
- acpi_memory_info : [RFC PATCH 2/13]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 4/13]
- iomem_resource: [RFC PATCH 5/13]
- mem_section and related sysfs files : [RFC PATCH 6-11/13]
- node and related sysfs files : [RFC PATCH 12-13/13]
The patches cannot do following things yet:
- page table of removed memory
If you find lack of function for physical memory hot-remove, please let me
know.
change log of v3:
* rebase to 3.5.0-rc6
[RFC PATCH v2 2/13]
* remove extra kobject_put()
* The patch was commented by Wen. Wen's comment is
acpi_memory_device_remove() should ignore a return value of
remove_memory() since caller does not care the return value.
But I did not change it since I think caller should care the
return value. And I am trying to fix it as follow:
https://lkml.org/lkml/2012/7/5/624
acpi_memory_device_remove() will be called not only when we write
1 to /sys/bus/acpi/devices/PNP0C80:XX/eject. When we unbind it
from the driver or remove the module acpi_memhotplug, this function
will be called too.
I will check whether your patch can work for these two cases.
I have checked it, and I think your patch can not work for these 2 cases.
When we unbind the device from the driver(write device name to
/sys/bus/acpi/drivers/acpi_memhotplug/unbind), driver_unbind()
will be called. This function does not care the return value.
When we remove the module acpi_memhotplug, acpi_memory_device_exit()
will be called. This function does not care the return value too.
I don't know whether there are some other cases that acpi_memory_device_remove()
will be called.
Thanks
Wen Congyang
Thanks
Wen Congyang
[RFC PATCH v2 4/13]
* remove a firmware_memmap_entry allocated by kzmalloc()
change log of v2:
[RFC PATCH v2 2/13]
* check whether memory block is offline or not before calling
offline_memory()
* check whether section is valid or not in is_memblk_offline()
* call kobject_put() for each memory_block in is_memblk_offline()
[RFC PATCH v2 3/13]
* unify the end argument of firmware_map_add_early/hotplug
[RFC PATCH v2 4/13]
* add release_firmware_map_entry() for freeing firmware_map_entry
[RFC PATCH v2 6/13]
* add release_memory_block() for freeing memory_block
[RFC PATCH v2 11/13]
* fix wrong arguments of free_pages()
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 16 +-
arch/x86/mm/init_64.c | 144
drivers/acpi/acpi_memhotplug.c | 28
drivers/base/memory.c | 54 -
drivers/base/node.c |7 +
drivers/firmware/memmap.c | 78 -
include/linux/firmware-map.h|6 +
include/linux/memory.h |5
include/linux/memory_hotplug.h | 17 --
include/linux/mm.h |5
mm/memory_hotplug.c | 98
mm/sparse.c |5
12 files changed, 414 insertions(+), 49 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to majord...@vger.kernel.org
More
Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote: Even if you apply these patches, you cannot remove the physical memory completely since these patches are still under development. I want you to cooperate to improve the physical memory hot-remove. So please review these patches and give your comment/idea. Could you at least give a method on how you want to do physical memory removal? You would have to remove all objects from the range you want to physically remove. That is only possible under special circumstances and with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE you still may get cases where pages are pinned for a long time. I am not sure that these patches are useful unless we know where you are going with this. If we end up with a situation where we still cannot remove physical memory then this patchset is not helpful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
