Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Tue, Sep 18, 2012 at 05:39:37PM +0800, Wen Congyang wrote: > At 09/13/2012 01:18 AM, Vasilis Liaskovitis Wrote: > > Hi, > > > > On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: > >> Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for > >> dimm > >> device, so I think we should support SLIT in seabios. Otherwise we may meet > >> the following kernel messages: > >> [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] > >> [ 325.018060] [mem 0x4000-0x5fff] page 2M > >> [ 325.019168] [ea000100-ea00011f] potential offnode > >> page_structs > >> [ 325.024172] [ea000120-ea00013f] potential offnode > >> page_structs > >> [ 325.028596] [ea000140-ea00017f] PMD -> > >> [88003500-8800353f] on node 1 > >> [ 325.031775] [ea000160-ea00017f] potential offnode > >> page_structs > >> > >> Do you have plan to do it? > > thanks for testing. > > > > commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 > > implements a SLIT table for the given numa nodes. > > Hmm, why do you set node_distance(i, j) to REMOTE_DISTANCE if i != j? What's the alternative? Afaik SLIT[i][j] shows the distance between proximity domains (_PXM) i and j. It doesn't correspond to individual SRAT entries. So i and j here are not memory ranges associated with 2 different dimms. They denote domains i and j, which map to 2 different logical nodeids in the kernel. A default setting would be to set the entry to REMOTE_DISTANCE for all different domains (i!=j). So this SLIT implementation is not useful, since it results in the same numa_distance values as the non-SLIT kernel calculation in include/linux/topology.h > > > > > However I am not sure the SLIT is the problem. The kernel builds a default > > numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the > > BIOS > > doesn't present a SLIT, this should take effect (numactl --hardware should > > report this table) > > If the BIOS doesn't present a SLIT, numa_distance_cnt is set to 0 in the > function numa_reset_distance(). So node_distance(i, j) is REMOTE_DISTANCE(i > != j). > > > > > Do you have more details on how to reproduce the warning? e.g. how many > > dimms > > are present in the system? Does this happen on the first dimm hot-plugged? > > Are all SRAT entries parsed correctly at boot-time or do you see any other > > warnings at boot-time? > > I can't reproduce it again. IIRC, I only do the following things: > hotplug a memory device, online the pages, offline the pages and hot remove > the memory device. Is the sparse_vmemmap allocation supposed to guarantee no off-node allocations? If not, then the warning could be valid. thanks, - Vasilis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Tue, Sep 18, 2012 at 05:39:37PM +0800, Wen Congyang wrote: At 09/13/2012 01:18 AM, Vasilis Liaskovitis Wrote: Hi, On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm device, so I think we should support SLIT in seabios. Otherwise we may meet the following kernel messages: [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] [ 325.018060] [mem 0x4000-0x5fff] page 2M [ 325.019168] [ea000100-ea00011f] potential offnode page_structs [ 325.024172] [ea000120-ea00013f] potential offnode page_structs [ 325.028596] [ea000140-ea00017f] PMD - [88003500-8800353f] on node 1 [ 325.031775] [ea000160-ea00017f] potential offnode page_structs Do you have plan to do it? thanks for testing. commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 implements a SLIT table for the given numa nodes. Hmm, why do you set node_distance(i, j) to REMOTE_DISTANCE if i != j? What's the alternative? Afaik SLIT[i][j] shows the distance between proximity domains (_PXM) i and j. It doesn't correspond to individual SRAT entries. So i and j here are not memory ranges associated with 2 different dimms. They denote domains i and j, which map to 2 different logical nodeids in the kernel. A default setting would be to set the entry to REMOTE_DISTANCE for all different domains (i!=j). So this SLIT implementation is not useful, since it results in the same numa_distance values as the non-SLIT kernel calculation in include/linux/topology.h However I am not sure the SLIT is the problem. The kernel builds a default numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS doesn't present a SLIT, this should take effect (numactl --hardware should report this table) If the BIOS doesn't present a SLIT, numa_distance_cnt is set to 0 in the function numa_reset_distance(). So node_distance(i, j) is REMOTE_DISTANCE(i != j). Do you have more details on how to reproduce the warning? e.g. how many dimms are present in the system? Does this happen on the first dimm hot-plugged? Are all SRAT entries parsed correctly at boot-time or do you see any other warnings at boot-time? I can't reproduce it again. IIRC, I only do the following things: hotplug a memory device, online the pages, offline the pages and hot remove the memory device. Is the sparse_vmemmap allocation supposed to guarantee no off-node allocations? If not, then the warning could be valid. thanks, - Vasilis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/13/2012 01:18 AM, Vasilis Liaskovitis Wrote: > Hi, > > On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: >>> >>> On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: > How do you test the patch? As Andrew says, for hot-removing memory, > we need a particular hardware. I think so too. So many people may want > to know how to test the patch. > If we apply following patch to kvm guest, can we hot-remove memory on > kvm guest? > > http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. >>> >>> the following repos contain the patchset above, plus 2 more patches that add >>> PS3 support to the dimm devices in qemu/seabios: >>> >>> https://github.com/vliaskov/seabios/commits/memhp-v2 >>> https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 >>> >>> I have not posted the PS3 patches yet in the qemu list, but will post them >>> soon for v3 of the memory hotplug series. If you have issues testing, let me >>> know. >> >> Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm >> device, so I think we should support SLIT in seabios. Otherwise we may meet >> the following kernel messages: >> [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] >> [ 325.018060] [mem 0x4000-0x5fff] page 2M >> [ 325.019168] [ea000100-ea00011f] potential offnode >> page_structs >> [ 325.024172] [ea000120-ea00013f] potential offnode >> page_structs >> [ 325.028596] [ea000140-ea00017f] PMD -> >> [88003500-8800353f] on node 1 >> [ 325.031775] [ea000160-ea00017f] potential offnode >> page_structs >> >> Do you have plan to do it? > thanks for testing. > > commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 > implements a SLIT table for the given numa nodes. Hmm, why do you set node_distance(i, j) to REMOTE_DISTANCE if i != j? > > However I am not sure the SLIT is the problem. The kernel builds a default > numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS > doesn't present a SLIT, this should take effect (numactl --hardware should > report this table) If the BIOS doesn't present a SLIT, numa_distance_cnt is set to 0 in the function numa_reset_distance(). So node_distance(i, j) is REMOTE_DISTANCE(i != j). > > Do you have more details on how to reproduce the warning? e.g. how many dimms > are present in the system? Does this happen on the first dimm hot-plugged? > Are all SRAT entries parsed correctly at boot-time or do you see any other > warnings at boot-time? I can't reproduce it again. IIRC, I only do the following things: hotplug a memory device, online the pages, offline the pages and hot remove the memory device. Thanks Wen Congyang > > I 'll investigate a bit more and report back. > > thanks, > > - Vasilis > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/13/2012 01:18 AM, Vasilis Liaskovitis Wrote: Hi, On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm device, so I think we should support SLIT in seabios. Otherwise we may meet the following kernel messages: [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] [ 325.018060] [mem 0x4000-0x5fff] page 2M [ 325.019168] [ea000100-ea00011f] potential offnode page_structs [ 325.024172] [ea000120-ea00013f] potential offnode page_structs [ 325.028596] [ea000140-ea00017f] PMD - [88003500-8800353f] on node 1 [ 325.031775] [ea000160-ea00017f] potential offnode page_structs Do you have plan to do it? thanks for testing. commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 implements a SLIT table for the given numa nodes. Hmm, why do you set node_distance(i, j) to REMOTE_DISTANCE if i != j? However I am not sure the SLIT is the problem. The kernel builds a default numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS doesn't present a SLIT, this should take effect (numactl --hardware should report this table) If the BIOS doesn't present a SLIT, numa_distance_cnt is set to 0 in the function numa_reset_distance(). So node_distance(i, j) is REMOTE_DISTANCE(i != j). Do you have more details on how to reproduce the warning? e.g. how many dimms are present in the system? Does this happen on the first dimm hot-plugged? Are all SRAT entries parsed correctly at boot-time or do you see any other warnings at boot-time? I can't reproduce it again. IIRC, I only do the following things: hotplug a memory device, online the pages, offline the pages and hot remove the memory device. Thanks Wen Congyang I 'll investigate a bit more and report back. thanks, - Vasilis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: > > > > On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: > >> At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: > >>> How do you test the patch? As Andrew says, for hot-removing memory, > >>> we need a particular hardware. I think so too. So many people may want > >>> to know how to test the patch. > >>> If we apply following patch to kvm guest, can we hot-remove memory on > >>> kvm guest? > >>> > >>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html > >> > >> Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. > >> But that patchset doesn't implement _PS3, so there is some restriction. > > > > the following repos contain the patchset above, plus 2 more patches that add > > PS3 support to the dimm devices in qemu/seabios: > > > > https://github.com/vliaskov/seabios/commits/memhp-v2 > > https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 > > > > I have not posted the PS3 patches yet in the qemu list, but will post them > > soon for v3 of the memory hotplug series. If you have issues testing, let me > > know. > > Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm > device, so I think we should support SLIT in seabios. Otherwise we may meet > the following kernel messages: > [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] > [ 325.018060] [mem 0x4000-0x5fff] page 2M > [ 325.019168] [ea000100-ea00011f] potential offnode > page_structs > [ 325.024172] [ea000120-ea00013f] potential offnode > page_structs > [ 325.028596] [ea000140-ea00017f] PMD -> > [88003500-8800353f] on node 1 > [ 325.031775] [ea000160-ea00017f] potential offnode > page_structs > > Do you have plan to do it? thanks for testing. commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 implements a SLIT table for the given numa nodes. However I am not sure the SLIT is the problem. The kernel builds a default numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS doesn't present a SLIT, this should take effect (numactl --hardware should report this table) Do you have more details on how to reproduce the warning? e.g. how many dimms are present in the system? Does this happen on the first dimm hot-plugged? Are all SRAT entries parsed correctly at boot-time or do you see any other warnings at boot-time? I 'll investigate a bit more and report back. thanks, - Vasilis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
On Tue, Sep 11, 2012 at 01:18:24PM +0800, Jerry wrote: > Hi Kim, > > Thank you for your kindness. Let me clarify this: > > On ARM architecture, there are 32 bits physical addresses space. However, > the addresses space is divided into 8 banks normally. Each bank > disabled/enabled by a chip selector signal. In my platform, bank0 connects > a DDR chip, and bank1 also connects another DDR chip. And each DDR chip > whose capability is 512MB is integrated into the main board. So, it could > not be removed by hand. We can disable/enable each bank by peripheral > device controller registers. > > When system enter suspend state, if all the pages allocated could be > migrated to one bank, there are no valid data in the another bank. In this > time, I could disable the free bank. It isn't necessary to provided power > to this chip in the suspend state. When system resume, I just need to > enable it again. > Yes. I already know it and other trials for that a few years ago[1]. A few years ago, I investigated the benefit between power consumption benefit during suspend VS start-up latency of resume and power consumption cost of migration(page migration and IO write for migration) and concluded normally the gain is not big. :) The situation could be changed these days as workload are changing but I'm skeptical about that approach, still. Anyway, it's my private thought so you don't need to care about that. If you are ready to submit the patchset, please send out. 1. http://lwn.net/Articles/478049/ Thanks. - Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
On Tue, Sep 11, 2012 at 01:18:24PM +0800, Jerry wrote: Hi Kim, Thank you for your kindness. Let me clarify this: On ARM architecture, there are 32 bits physical addresses space. However, the addresses space is divided into 8 banks normally. Each bank disabled/enabled by a chip selector signal. In my platform, bank0 connects a DDR chip, and bank1 also connects another DDR chip. And each DDR chip whose capability is 512MB is integrated into the main board. So, it could not be removed by hand. We can disable/enable each bank by peripheral device controller registers. When system enter suspend state, if all the pages allocated could be migrated to one bank, there are no valid data in the another bank. In this time, I could disable the free bank. It isn't necessary to provided power to this chip in the suspend state. When system resume, I just need to enable it again. Yes. I already know it and other trials for that a few years ago[1]. A few years ago, I investigated the benefit between power consumption benefit during suspend VS start-up latency of resume and power consumption cost of migration(page migration and IO write for migration) and concluded normally the gain is not big. :) The situation could be changed these days as workload are changing but I'm skeptical about that approach, still. Anyway, it's my private thought so you don't need to care about that. If you are ready to submit the patchset, please send out. 1. http://lwn.net/Articles/478049/ Thanks. - Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote: On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm device, so I think we should support SLIT in seabios. Otherwise we may meet the following kernel messages: [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] [ 325.018060] [mem 0x4000-0x5fff] page 2M [ 325.019168] [ea000100-ea00011f] potential offnode page_structs [ 325.024172] [ea000120-ea00013f] potential offnode page_structs [ 325.028596] [ea000140-ea00017f] PMD - [88003500-8800353f] on node 1 [ 325.031775] [ea000160-ea00017f] potential offnode page_structs Do you have plan to do it? thanks for testing. commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2 implements a SLIT table for the given numa nodes. However I am not sure the SLIT is the problem. The kernel builds a default numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS doesn't present a SLIT, this should take effect (numactl --hardware should report this table) Do you have more details on how to reproduce the warning? e.g. how many dimms are present in the system? Does this happen on the first dimm hot-plugged? Are all SRAT entries parsed correctly at boot-time or do you see any other warnings at boot-time? I 'll investigate a bit more and report back. thanks, - Vasilis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/10/2012 09:52 PM, Vasilis Liaskovitis Wrote: > Hi, > > On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: >> At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: >>> Hi Wen, >>> >>> 2012/09/01 5:49, Andrew Morton wrote: On Tue, 28 Aug 2012 18:00:07 +0800 we...@cn.fujitsu.com wrote: > This patch series aims to support physical memory hot-remove. I doubt if many people have hardware which permits physical memory removal? How would you suggest that people with regular hardware can test these chagnes? >>> >>> How do you test the patch? As Andrew says, for hot-removing memory, >>> we need a particular hardware. I think so too. So many people may want >>> to know how to test the patch. >>> If we apply following patch to kvm guest, can we hot-remove memory on >>> kvm guest? >>> >>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html >> >> Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. >> But that patchset doesn't implement _PS3, so there is some restriction. > > the following repos contain the patchset above, plus 2 more patches that add > PS3 support to the dimm devices in qemu/seabios: > > https://github.com/vliaskov/seabios/commits/memhp-v2 > https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 > > I have not posted the PS3 patches yet in the qemu list, but will post them > soon for v3 of the memory hotplug series. If you have issues testing, let me > know. Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm device, so I think we should support SLIT in seabios. Otherwise we may meet the following kernel messages: [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] [ 325.018060] [mem 0x4000-0x5fff] page 2M [ 325.019168] [ea000100-ea00011f] potential offnode page_structs [ 325.024172] [ea000120-ea00013f] potential offnode page_structs [ 325.028596] [ea000140-ea00017f] PMD -> [88003500-8800353f] on node 1 [ 325.031775] [ea000160-ea00017f] potential offnode page_structs Do you have plan to do it? Thanks Wen Congyang > > thanks, > > - Vasilis > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/10/2012 09:52 PM, Vasilis Liaskovitis Wrote: Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: Hi Wen, 2012/09/01 5:49, Andrew Morton wrote: On Tue, 28 Aug 2012 18:00:07 +0800 we...@cn.fujitsu.com wrote: This patch series aims to support physical memory hot-remove. I doubt if many people have hardware which permits physical memory removal? How would you suggest that people with regular hardware can test these chagnes? How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm device, so I think we should support SLIT in seabios. Otherwise we may meet the following kernel messages: [ 325.016769] init_memory_mapping: [mem 0x4000-0x5fff] [ 325.018060] [mem 0x4000-0x5fff] page 2M [ 325.019168] [ea000100-ea00011f] potential offnode page_structs [ 325.024172] [ea000120-ea00013f] potential offnode page_structs [ 325.028596] [ea000140-ea00017f] PMD - [88003500-8800353f] on node 1 [ 325.031775] [ea000160-ea00017f] potential offnode page_structs Do you have plan to do it? Thanks Wen Congyang thanks, - Vasilis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/11/2012 01:18 PM, Jerry Wrote: > Hi Kim, > > Thank you for your kindness. Let me clarify this: > > On ARM architecture, there are 32 bits physical addresses space. However, > the addresses space is divided into 8 banks normally. Each bank > disabled/enabled by a chip selector signal. In my platform, bank0 connects > a DDR chip, and bank1 also connects another DDR chip. And each DDR chip > whose capability is 512MB is integrated into the main board. So, it could > not be removed by hand. We can disable/enable each bank by peripheral > device controller registers. > > When system enter suspend state, if all the pages allocated could be > migrated to one bank, there are no valid data in the another bank. In this > time, I could disable the free bank. It isn't necessary to provided power > to this chip in the suspend state. When system resume, I just need to > enable it again. > > Hi Wen, > > I am sorry for that I doesn't know the "_PSx support" means. Maybe I > needn't it. Hmm, arm doesn't support ACPI, so please ignore it. Thanks Wen Congyang > > Thanks, > Jerry > > 2012/9/11 Minchan Kim > >> Hi Jerry, >> >> On Tue, Sep 11, 2012 at 08:27:40AM +0800, Jerry wrote: >>> Hi Wen, >>> >>> I have been arranged a job related memory hotplug on ARM architecture. >>> Maybe I know some new issues about memory hotplug on ARM architecture. I >>> just enabled it on ARM, and it works well in my Android tablet now. >>> However, I have not send out my patches. The real reason is that I don't >>> know how to do it. Maybe I need to read >> "Documentation/SubmittingPatches". >>> >>> Hi Andrew, >>> This is my first time to send you a e-mail. I am so nervous about if I >> have >>> some mistakes or not. >> >> Don't be afraid. >> If you might make a mistake, it's very natural to newbie. >> I am sure anyone doesn't blame you. :) >> If you have a good patch, please send out. >> >>> >>> Some peoples maybe think memory hotplug need to be supported by special >>> hardware. Maybe it means memory physical hotplug. Some times, we just >> need >>> to use memory logical hotplug, doesn't remove the memory in physical. It >> is >>> also usefully for power saving in my platform. Because I doesn't want >>> the offline memory is in *self-refresh* state. >> >> Just out of curiosity. >> What's the your scenario and gain? >> AFAIK, there were some effort about it in embedded side but gain isn't >> rather big >> IIRC. >> >>> >>> Any comments are appreciated. >>> >>> Thanks, >>> Jerry >>> >>> 2012/9/10 Vasilis Liaskovitis >>> Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: > At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: >> Hi Wen, >> >> 2012/09/01 5:49, Andrew Morton wrote: >>> On Tue, 28 Aug 2012 18:00:07 +0800 >>> we...@cn.fujitsu.com wrote: >>> This patch series aims to support physical memory hot-remove. >>> >>> I doubt if many people have hardware which permits physical memory >>> removal? How would you suggest that people with regular hardware >> can >>> test these chagnes? >> >> How do you test the patch? As Andrew says, for hot-removing memory, >> we need a particular hardware. I think so too. So many people may >> want >> to know how to test the patch. >> If we apply following patch to kvm guest, can we hot-remove memory >> on >> kvm guest? >> >> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html > > Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. > But that patchset doesn't implement _PS3, so there is some >> restriction. the following repos contain the patchset above, plus 2 more patches >> that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post >> them soon for v3 of the memory hotplug series. If you have issues testing, >> let me know. thanks, - Vasilis -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org >>> >>> >>> >>> -- >>> I love linux!!! >> >> -- >> Kind regards, >> Minchan Kim >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi Jerry, On Tue, Sep 11, 2012 at 08:27:40AM +0800, Jerry wrote: > Hi Wen, > > I have been arranged a job related memory hotplug on ARM architecture. > Maybe I know some new issues about memory hotplug on ARM architecture. I > just enabled it on ARM, and it works well in my Android tablet now. > However, I have not send out my patches. The real reason is that I don't > know how to do it. Maybe I need to read "Documentation/SubmittingPatches". > > Hi Andrew, > This is my first time to send you a e-mail. I am so nervous about if I have > some mistakes or not. Don't be afraid. If you might make a mistake, it's very natural to newbie. I am sure anyone doesn't blame you. :) If you have a good patch, please send out. > > Some peoples maybe think memory hotplug need to be supported by special > hardware. Maybe it means memory physical hotplug. Some times, we just need > to use memory logical hotplug, doesn't remove the memory in physical. It is > also usefully for power saving in my platform. Because I doesn't want > the offline memory is in *self-refresh* state. Just out of curiosity. What's the your scenario and gain? AFAIK, there were some effort about it in embedded side but gain isn't rather big IIRC. > > Any comments are appreciated. > > Thanks, > Jerry > > 2012/9/10 Vasilis Liaskovitis > > > Hi, > > > > On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: > > > At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: > > > > Hi Wen, > > > > > > > > 2012/09/01 5:49, Andrew Morton wrote: > > > >> On Tue, 28 Aug 2012 18:00:07 +0800 > > > >> we...@cn.fujitsu.com wrote: > > > >> > > > >>> This patch series aims to support physical memory hot-remove. > > > >> > > > >> I doubt if many people have hardware which permits physical memory > > > >> removal? How would you suggest that people with regular hardware can > > > >> test these chagnes? > > > > > > > > How do you test the patch? As Andrew says, for hot-removing memory, > > > > we need a particular hardware. I think so too. So many people may want > > > > to know how to test the patch. > > > > If we apply following patch to kvm guest, can we hot-remove memory on > > > > kvm guest? > > > > > > > > http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html > > > > > > Yes, if we apply this patchset, we can test hot-remove memory on kvm > > guest. > > > But that patchset doesn't implement _PS3, so there is some restriction. > > > > the following repos contain the patchset above, plus 2 more patches that > > add > > PS3 support to the dimm devices in qemu/seabios: > > > > https://github.com/vliaskov/seabios/commits/memhp-v2 > > https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 > > > > I have not posted the PS3 patches yet in the qemu list, but will post them > > soon for v3 of the memory hotplug series. If you have issues testing, let > > me > > know. > > > > thanks, > > > > - Vasilis > > > > -- > > To unsubscribe, send a message with 'unsubscribe linux-mm' in > > the body to majord...@kvack.org. For more info on Linux MM, > > see: http://www.linux-mm.org/ . > > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > > > > > > -- > I love linux!!! -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/11/2012 08:27 AM, Jerry Wrote: > Hi Wen, > > I have been arranged a job related memory hotplug on ARM architecture. > Maybe I know some new issues about memory hotplug on ARM architecture. I > just enabled it on ARM, and it works well in my Android tablet now. > However, I have not send out my patches. The real reason is that I don't > know how to do it. Maybe I need to read "Documentation/SubmittingPatches". > > Hi Andrew, > This is my first time to send you a e-mail. I am so nervous about if I have > some mistakes or not. > > Some peoples maybe think memory hotplug need to be supported by special > hardware. Maybe it means memory physical hotplug. Some times, we just need > to use memory logical hotplug, doesn't remove the memory in physical. It is > also usefully for power saving in my platform. Because I doesn't want > the offline memory is in *self-refresh* state. Power saving? Do you need _PSx support? Thanks Wen Congyang > > Any comments are appreciated. > > Thanks, > Jerry > > 2012/9/10 Vasilis Liaskovitis > >> Hi, >> >> On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: >>> At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: Hi Wen, 2012/09/01 5:49, Andrew Morton wrote: > On Tue, 28 Aug 2012 18:00:07 +0800 > we...@cn.fujitsu.com wrote: > >> This patch series aims to support physical memory hot-remove. > > I doubt if many people have hardware which permits physical memory > removal? How would you suggest that people with regular hardware can > test these chagnes? How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html >>> >>> Yes, if we apply this patchset, we can test hot-remove memory on kvm >> guest. >>> But that patchset doesn't implement _PS3, so there is some restriction. >> >> the following repos contain the patchset above, plus 2 more patches that >> add >> PS3 support to the dimm devices in qemu/seabios: >> >> https://github.com/vliaskov/seabios/commits/memhp-v2 >> https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 >> >> I have not posted the PS3 patches yet in the qemu list, but will post them >> soon for v3 of the memory hotplug series. If you have issues testing, let >> me >> know. >> >> thanks, >> >> - Vasilis >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majord...@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: mailto:"d...@kvack.org;> em...@kvack.org >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: > At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: > > Hi Wen, > > > > 2012/09/01 5:49, Andrew Morton wrote: > >> On Tue, 28 Aug 2012 18:00:07 +0800 > >> we...@cn.fujitsu.com wrote: > >> > >>> This patch series aims to support physical memory hot-remove. > >> > >> I doubt if many people have hardware which permits physical memory > >> removal? How would you suggest that people with regular hardware can > >> test these chagnes? > > > > How do you test the patch? As Andrew says, for hot-removing memory, > > we need a particular hardware. I think so too. So many people may want > > to know how to test the patch. > > If we apply following patch to kvm guest, can we hot-remove memory on > > kvm guest? > > > > http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html > > Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. > But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. thanks, - Vasilis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: Hi Wen, 2012/09/01 5:49, Andrew Morton wrote: On Tue, 28 Aug 2012 18:00:07 +0800 we...@cn.fujitsu.com wrote: This patch series aims to support physical memory hot-remove. I doubt if many people have hardware which permits physical memory removal? How would you suggest that people with regular hardware can test these chagnes? How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. thanks, - Vasilis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/11/2012 08:27 AM, Jerry Wrote: Hi Wen, I have been arranged a job related memory hotplug on ARM architecture. Maybe I know some new issues about memory hotplug on ARM architecture. I just enabled it on ARM, and it works well in my Android tablet now. However, I have not send out my patches. The real reason is that I don't know how to do it. Maybe I need to read Documentation/SubmittingPatches. Hi Andrew, This is my first time to send you a e-mail. I am so nervous about if I have some mistakes or not. Some peoples maybe think memory hotplug need to be supported by special hardware. Maybe it means memory physical hotplug. Some times, we just need to use memory logical hotplug, doesn't remove the memory in physical. It is also usefully for power saving in my platform. Because I doesn't want the offline memory is in *self-refresh* state. Power saving? Do you need _PSx support? Thanks Wen Congyang Any comments are appreciated. Thanks, Jerry 2012/9/10 Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: Hi Wen, 2012/09/01 5:49, Andrew Morton wrote: On Tue, 28 Aug 2012 18:00:07 +0800 we...@cn.fujitsu.com wrote: This patch series aims to support physical memory hot-remove. I doubt if many people have hardware which permits physical memory removal? How would you suggest that people with regular hardware can test these chagnes? How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. thanks, - Vasilis -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi Jerry, On Tue, Sep 11, 2012 at 08:27:40AM +0800, Jerry wrote: Hi Wen, I have been arranged a job related memory hotplug on ARM architecture. Maybe I know some new issues about memory hotplug on ARM architecture. I just enabled it on ARM, and it works well in my Android tablet now. However, I have not send out my patches. The real reason is that I don't know how to do it. Maybe I need to read Documentation/SubmittingPatches. Hi Andrew, This is my first time to send you a e-mail. I am so nervous about if I have some mistakes or not. Don't be afraid. If you might make a mistake, it's very natural to newbie. I am sure anyone doesn't blame you. :) If you have a good patch, please send out. Some peoples maybe think memory hotplug need to be supported by special hardware. Maybe it means memory physical hotplug. Some times, we just need to use memory logical hotplug, doesn't remove the memory in physical. It is also usefully for power saving in my platform. Because I doesn't want the offline memory is in *self-refresh* state. Just out of curiosity. What's the your scenario and gain? AFAIK, there were some effort about it in embedded side but gain isn't rather big IIRC. Any comments are appreciated. Thanks, Jerry 2012/9/10 Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: Hi Wen, 2012/09/01 5:49, Andrew Morton wrote: On Tue, 28 Aug 2012 18:00:07 +0800 we...@cn.fujitsu.com wrote: This patch series aims to support physical memory hot-remove. I doubt if many people have hardware which permits physical memory removal? How would you suggest that people with regular hardware can test these chagnes? How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. thanks, - Vasilis -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- I love linux!!! -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/11/2012 01:18 PM, Jerry Wrote: Hi Kim, Thank you for your kindness. Let me clarify this: On ARM architecture, there are 32 bits physical addresses space. However, the addresses space is divided into 8 banks normally. Each bank disabled/enabled by a chip selector signal. In my platform, bank0 connects a DDR chip, and bank1 also connects another DDR chip. And each DDR chip whose capability is 512MB is integrated into the main board. So, it could not be removed by hand. We can disable/enable each bank by peripheral device controller registers. When system enter suspend state, if all the pages allocated could be migrated to one bank, there are no valid data in the another bank. In this time, I could disable the free bank. It isn't necessary to provided power to this chip in the suspend state. When system resume, I just need to enable it again. Hi Wen, I am sorry for that I doesn't know the _PSx support means. Maybe I needn't it. Hmm, arm doesn't support ACPI, so please ignore it. Thanks Wen Congyang Thanks, Jerry 2012/9/11 Minchan Kim minc...@kernel.org Hi Jerry, On Tue, Sep 11, 2012 at 08:27:40AM +0800, Jerry wrote: Hi Wen, I have been arranged a job related memory hotplug on ARM architecture. Maybe I know some new issues about memory hotplug on ARM architecture. I just enabled it on ARM, and it works well in my Android tablet now. However, I have not send out my patches. The real reason is that I don't know how to do it. Maybe I need to read Documentation/SubmittingPatches. Hi Andrew, This is my first time to send you a e-mail. I am so nervous about if I have some mistakes or not. Don't be afraid. If you might make a mistake, it's very natural to newbie. I am sure anyone doesn't blame you. :) If you have a good patch, please send out. Some peoples maybe think memory hotplug need to be supported by special hardware. Maybe it means memory physical hotplug. Some times, we just need to use memory logical hotplug, doesn't remove the memory in physical. It is also usefully for power saving in my platform. Because I doesn't want the offline memory is in *self-refresh* state. Just out of curiosity. What's the your scenario and gain? AFAIK, there were some effort about it in embedded side but gain isn't rather big IIRC. Any comments are appreciated. Thanks, Jerry 2012/9/10 Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com Hi, On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote: At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote: Hi Wen, 2012/09/01 5:49, Andrew Morton wrote: On Tue, 28 Aug 2012 18:00:07 +0800 we...@cn.fujitsu.com wrote: This patch series aims to support physical memory hot-remove. I doubt if many people have hardware which permits physical memory removal? How would you suggest that people with regular hardware can test these chagnes? How do you test the patch? As Andrew says, for hot-removing memory, we need a particular hardware. I think so too. So many people may want to know how to test the patch. If we apply following patch to kvm guest, can we hot-remove memory on kvm guest? http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html Yes, if we apply this patchset, we can test hot-remove memory on kvm guest. But that patchset doesn't implement _PS3, so there is some restriction. the following repos contain the patchset above, plus 2 more patches that add PS3 support to the dimm devices in qemu/seabios: https://github.com/vliaskov/seabios/commits/memhp-v2 https://github.com/vliaskov/qemu-kvm/commits/memhp-v2 I have not posted the PS3 patches yet in the qemu list, but will post them soon for v3 of the memory hotplug series. If you have issues testing, let me know. thanks, - Vasilis -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- I love linux!!! -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/09/01 5:49, Andrew Morton wrote:
>> On Tue, 28 Aug 2012 18:00:07 +0800
>> we...@cn.fujitsu.com wrote:
>>
>>> This patch series aims to support physical memory hot-remove.
>>
>> Have you had much review and testing feedback yet?
>>
>>> The patches can free/remove the following things:
>>>
>>>- acpi_memory_info : [RFC PATCH 4/19]
>>>- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
>>>- iomem_resource: [RFC PATCH 9/19]
>>>- mem_section and related sysfs files : [RFC PATCH 10-11,
>>> 13-16/19]
>>>- page table of removed memory : [RFC PATCH 12/19]
>>>- node and related sysfs files : [RFC PATCH 18-19/19]
>>>
>>> If you find lack of function for physical memory hot-remove, please
>>> let me
>>> know.
>>
>
>> I doubt if many people have hardware which permits physical memory
>> removal? How would you suggest that people with regular hardware can
>> test these chagnes?
>
> How do you test the patch? As Andrew says, for hot-removing memory,
> we need a particular hardware. I think so too. So many people may want
> to know how to test the patch.
> If we apply following patch to kvm guest, can we hot-remove memory on
> kvm guest?
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
Yes, if we apply this patchset, we can test hot-remove memory on kvm guest.
But that patchset doesn't implement _PS3, so there is some restriction.
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>>> Known problems:
>>> 1. memory can't be offlined when CONFIG_MEMCG is selected.
>>
>> That's quite a problem! Do you have a description of why this is the
>> case, and a plan for fixing it?
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi Wen,
2012/09/01 5:49, Andrew Morton wrote:
On Tue, 28 Aug 2012 18:00:07 +0800
we...@cn.fujitsu.com wrote:
This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
How do you test the patch? As Andrew says, for hot-removing memory,
we need a particular hardware. I think so too. So many people may want
to know how to test the patch.
If we apply following patch to kvm guest, can we hot-remove memory on
kvm guest?
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
Thanks,
Yasuaki Ishimatsu
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
Hi Wen,
2012/09/01 5:49, Andrew Morton wrote:
On Tue, 28 Aug 2012 18:00:07 +0800
we...@cn.fujitsu.com wrote:
This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
How do you test the patch? As Andrew says, for hot-removing memory,
we need a particular hardware. I think so too. So many people may want
to know how to test the patch.
If we apply following patch to kvm guest, can we hot-remove memory on
kvm guest?
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
Thanks,
Yasuaki Ishimatsu
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/09/01 5:49, Andrew Morton wrote:
On Tue, 28 Aug 2012 18:00:07 +0800
we...@cn.fujitsu.com wrote:
This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11,
13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please
let me
know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
How do you test the patch? As Andrew says, for hot-removing memory,
we need a particular hardware. I think so too. So many people may want
to know how to test the patch.
If we apply following patch to kvm guest, can we hot-remove memory on
kvm guest?
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
Yes, if we apply this patchset, we can test hot-remove memory on kvm guest.
But that patchset doesn't implement _PS3, so there is some restriction.
Thanks
Wen Congyang
Thanks,
Yasuaki Ishimatsu
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
On Tue, 28 Aug 2012 18:00:07 +0800
we...@cn.fujitsu.com wrote:
> This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
> The patches can free/remove the following things:
>
> - acpi_memory_info : [RFC PATCH 4/19]
> - /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
> - iomem_resource: [RFC PATCH 9/19]
> - mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
> - page table of removed memory : [RFC PATCH 12/19]
> - node and related sysfs files : [RFC PATCH 18-19/19]
>
> If you find lack of function for physical memory hot-remove, please let me
> know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
> Known problems:
> 1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
On Tue, 28 Aug 2012 18:00:07 +0800
we...@cn.fujitsu.com wrote:
This patch series aims to support physical memory hot-remove.
Have you had much review and testing feedback yet?
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
I doubt if many people have hardware which permits physical memory
removal? How would you suggest that people with regular hardware can
test these chagnes?
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
That's quite a problem! Do you have a description of why this is the
case, and a plan for fixing it?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
From: Wen Congyang
This patch series aims to support physical memory hot-remove.
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
change log of v8:
[RFC PATCH v8 17/20]
* Fix problems when one node's range include the other nodes
[RFC PATCH v8 18/20]
* fix building error when CONFIG_MEMORY_HOTPLUG_SPARSE or CONFIG_HUGETLBFS
is not defined.
[RFC PATCH v8 19/20]
* don't offline node when some memory sections are not removed
[RFC PATCH v8 20/20]
* create new patch: clear hwpoisoned flag when onlining pages
change log of v7:
[RFC PATCH v7 4/19]
* do not continue if acpi_memory_device_remove_memory() fails.
[RFC PATCH v7 15/19]
* handle usemap in register_page_bootmem_info_section() too.
change log of v6:
[RFC PATCH v6 12/19]
* fix building error on other archtitectures than x86
[RFC PATCH v6 15-16/19]
* fix building error on other archtitectures than x86
change log of v5:
* merge the patchset to clear page table and the patchset to hot remove
memory(from ishimatsu) to one big patchset.
[RFC PATCH v5 1/19]
* rename remove_memory() to offline_memory()/offline_pages()
[RFC PATCH v5 2/19]
* new patch: implement offline_memory(). This function offlines pages,
update memory block's state, and notify the userspace that the memory
block's state is changed.
[RFC PATCH v5 4/19]
* offline and remove memory in acpi_memory_disable_device() too.
[RFC PATCH v5 17/19]
* new patch: add a new function __remove_zone() to revert the things done
in the function __add_zone().
[RFC PATCH v5 18/19]
* flush work befor reseting node device.
change log of v4:
* remove "memory-hotplug : unify argument of firmware_map_add_early/hotplug"
from the patch series, since the patch is a bugfix. It is being disccussed
on other thread. But for testing the patch series, the patch is needed.
So I added the patch as [PATCH 0/13].
[RFC PATCH v4 2/13]
* check memory is online or not at remove_memory()
* add memory_add_physaddr_to_nid() to acpi_memory_device_remove() for
getting node id
[RFC PATCH v4 3/13]
* create new patch : check memory is online or not at online_pages()
[RFC PATCH v4 4/13]
* add __ref section to remove_memory()
* call firmware_map_remove_entry() before remove_sysfs_fw_map_entry()
[RFC PATCH v4 11/13]
* rewrite register_page_bootmem_memmap() for removing page used as PT/PMD
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
[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()
Wen Congyang (7):
memory-hotplug: implement offline_memory()
memory-hotplug: store the node id in acpi_memory_device
memory-hotplug: export the function acpi_bus_remove()
memory-hotplug: call acpi_bus_remove() to remove memory device
memory-hotplug: introduce new function arch_remove_memory()
memory-hotplug: remove sysfs file of node
memory-hotplug: clear hwpoisoned flag when onlining pages
Yasuaki Ishimatsu (13):
memory-hotplug: rename remove_memory() to
offline_memory()/offline_pages()
memory-hotplug: offline and remove memory when removing the memory
device
memory-hotplug: check whether memory is present or not
memory-hotplug: remove /sys/firmware/memmap/X sysfs
memory-hotplug: does not release memory region in PAGES_PER_SECTION
chunks
memory-hotplug: add memory_block_release
memory-hotplug: remove_memory calls __remove_pages
memory-hotplug: check
[RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
From: Wen Congyang we...@cn.fujitsu.com
This patch series aims to support physical memory hot-remove.
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
change log of v8:
[RFC PATCH v8 17/20]
* Fix problems when one node's range include the other nodes
[RFC PATCH v8 18/20]
* fix building error when CONFIG_MEMORY_HOTPLUG_SPARSE or CONFIG_HUGETLBFS
is not defined.
[RFC PATCH v8 19/20]
* don't offline node when some memory sections are not removed
[RFC PATCH v8 20/20]
* create new patch: clear hwpoisoned flag when onlining pages
change log of v7:
[RFC PATCH v7 4/19]
* do not continue if acpi_memory_device_remove_memory() fails.
[RFC PATCH v7 15/19]
* handle usemap in register_page_bootmem_info_section() too.
change log of v6:
[RFC PATCH v6 12/19]
* fix building error on other archtitectures than x86
[RFC PATCH v6 15-16/19]
* fix building error on other archtitectures than x86
change log of v5:
* merge the patchset to clear page table and the patchset to hot remove
memory(from ishimatsu) to one big patchset.
[RFC PATCH v5 1/19]
* rename remove_memory() to offline_memory()/offline_pages()
[RFC PATCH v5 2/19]
* new patch: implement offline_memory(). This function offlines pages,
update memory block's state, and notify the userspace that the memory
block's state is changed.
[RFC PATCH v5 4/19]
* offline and remove memory in acpi_memory_disable_device() too.
[RFC PATCH v5 17/19]
* new patch: add a new function __remove_zone() to revert the things done
in the function __add_zone().
[RFC PATCH v5 18/19]
* flush work befor reseting node device.
change log of v4:
* remove memory-hotplug : unify argument of firmware_map_add_early/hotplug
from the patch series, since the patch is a bugfix. It is being disccussed
on other thread. But for testing the patch series, the patch is needed.
So I added the patch as [PATCH 0/13].
[RFC PATCH v4 2/13]
* check memory is online or not at remove_memory()
* add memory_add_physaddr_to_nid() to acpi_memory_device_remove() for
getting node id
[RFC PATCH v4 3/13]
* create new patch : check memory is online or not at online_pages()
[RFC PATCH v4 4/13]
* add __ref section to remove_memory()
* call firmware_map_remove_entry() before remove_sysfs_fw_map_entry()
[RFC PATCH v4 11/13]
* rewrite register_page_bootmem_memmap() for removing page used as PT/PMD
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
[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()
Wen Congyang (7):
memory-hotplug: implement offline_memory()
memory-hotplug: store the node id in acpi_memory_device
memory-hotplug: export the function acpi_bus_remove()
memory-hotplug: call acpi_bus_remove() to remove memory device
memory-hotplug: introduce new function arch_remove_memory()
memory-hotplug: remove sysfs file of node
memory-hotplug: clear hwpoisoned flag when onlining pages
Yasuaki Ishimatsu (13):
memory-hotplug: rename remove_memory() to
offline_memory()/offline_pages()
memory-hotplug: offline and remove memory when removing the memory
device
memory-hotplug: check whether memory is present or not
memory-hotplug: remove /sys/firmware/memmap/X sysfs
memory-hotplug: does not release memory region in PAGES_PER_SECTION
chunks
memory-hotplug: add memory_block_release
memory-hotplug: remove_memory calls __remove_pages
