| Message ID | 5241655E.1000007@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hello, On Tue, Sep 24, 2013 at 06:11:42PM +0800, Zhang Yanfei wrote: > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 36cfce3..2cf04fd 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1132,6 +1132,14 @@ void __init setup_arch(char **cmdline_p) > early_acpi_boot_init(); > > initmem_init(); > + > + /* > + * When ACPI SRAT is parsed, which is done in initmem_init(), > + * set memblock back to the top-down direction. > + */ > + if (memblock_bottom_up()) > + memblock_set_bottom_up(false); I don't think you need the if (). Just call memblock_set_bottom_up(false). > +static int __init cmdline_parse_movablenode(char *p) > +{ > + /* > + * Memory used by the kernel cannot be hot-removed because Linux > + * cannot migrate the kernel pages. When memory hotplug is > + * enabled, we should prevent memblock from allocating memory > + * for the kernel. > + * > + * ACPI SRAT records all hotpluggable memory ranges. But before > + * SRAT is parsed, we don't know about it. > + * > + * The kernel image is loaded into memory at very early time. We > + * cannot prevent this anyway. So on NUMA system, we set any > + * node the kernel resides in as un-hotpluggable. > + * > + * Since on modern servers, one node could have double-digit > + * gigabytes memory, we can assume the memory around the kernel > + * image is also un-hotpluggable. So before SRAT is parsed, just > + * allocate memory near the kernel image to try the best to keep > + * the kernel away from hotpluggable memory. > + */ > + memblock_set_bottom_up(true); > + return 0; > +} > +early_param("movablenode", cmdline_parse_movablenode); This came up during earlier review but never was addressed. Is "movablenode" the right name? Shouldn't it be something which explicitly shows that it's to prepare for memory hotplug? Also, maybe the above param should generate warning if CONFIG_MOVABLE_NODE isn't enabled? Thanks.
On 09/24/2013 08:41 PM, Tejun Heo wrote: > Hello, > > On Tue, Sep 24, 2013 at 06:11:42PM +0800, Zhang Yanfei wrote: >> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c >> index 36cfce3..2cf04fd 100644 >> --- a/arch/x86/kernel/setup.c >> +++ b/arch/x86/kernel/setup.c >> @@ -1132,6 +1132,14 @@ void __init setup_arch(char **cmdline_p) >> early_acpi_boot_init(); >> >> initmem_init(); >> + >> + /* >> + * When ACPI SRAT is parsed, which is done in initmem_init(), >> + * set memblock back to the top-down direction. >> + */ >> + if (memblock_bottom_up()) >> + memblock_set_bottom_up(false); > > I don't think you need the if (). Just call > memblock_set_bottom_up(false). OK, will remove it. > >> +static int __init cmdline_parse_movablenode(char *p) >> +{ >> + /* >> + * Memory used by the kernel cannot be hot-removed because Linux >> + * cannot migrate the kernel pages. When memory hotplug is >> + * enabled, we should prevent memblock from allocating memory >> + * for the kernel. >> + * >> + * ACPI SRAT records all hotpluggable memory ranges. But before >> + * SRAT is parsed, we don't know about it. >> + * >> + * The kernel image is loaded into memory at very early time. We >> + * cannot prevent this anyway. So on NUMA system, we set any >> + * node the kernel resides in as un-hotpluggable. >> + * >> + * Since on modern servers, one node could have double-digit >> + * gigabytes memory, we can assume the memory around the kernel >> + * image is also un-hotpluggable. So before SRAT is parsed, just >> + * allocate memory near the kernel image to try the best to keep >> + * the kernel away from hotpluggable memory. >> + */ >> + memblock_set_bottom_up(true); >> + return 0; >> +} >> +early_param("movablenode", cmdline_parse_movablenode); > > This came up during earlier review but never was addressed. Is > "movablenode" the right name? Shouldn't it be something which > explicitly shows that it's to prepare for memory hotplug? Also, maybe > the above param should generate warning if CONFIG_MOVABLE_NODE isn't > enabled? hmmm...as for the option name, if this option is set, it means, the kernel could support the functionality that a whole node is the so called movable node, which only has ZONE MOVABLE zone in it. So we choose to name the parameter "movablenode". As for the warning, will add it. Thanks > > Thanks. >
Hello tejun, On 09/24/2013 09:31 PM, Zhang Yanfei wrote: >> This came up during earlier review but never was addressed. Is >> > "movablenode" the right name? Shouldn't it be something which >> > explicitly shows that it's to prepare for memory hotplug? Also, maybe >> > the above param should generate warning if CONFIG_MOVABLE_NODE isn't >> > enabled? > hmmm...as for the option name, if this option is set, it means, the kernel > could support the functionality that a whole node is the so called > movable node, which only has ZONE MOVABLE zone in it. So we choose > to name the parameter "movablenode". > > As for the warning, will add it. I am now preparing the v5 version. Only in this patch we haven't come to an agreement. So as for the boot option name, after my explanation, do you still have the objection? Or you could suggest a good name for us, that'll be very thankful:) Thanks.
Hello, On Tue, Sep 24, 2013 at 11:24:48PM +0800, Zhang Yanfei wrote: > I am now preparing the v5 version. Only in this patch we haven't come to an > agreement. So as for the boot option name, after my explanation, do you still > have the objection? Or you could suggest a good name for us, that'll be > very thankful:) No particular idea and my concern about the name isn't very strong. It just doesn't seem like a good name to me. It's a bit obscure and we may want to do more things for hotplug later which may not fit the param name. If you guys think it's good enough, please go ahead. Thanks.
On 09/24/2013 11:32 PM, Tejun Heo wrote: > Hello, > > On Tue, Sep 24, 2013 at 11:24:48PM +0800, Zhang Yanfei wrote: >> I am now preparing the v5 version. Only in this patch we haven't come to an >> agreement. So as for the boot option name, after my explanation, do you still >> have the objection? Or you could suggest a good name for us, that'll be >> very thankful:) > > No particular idea and my concern about the name isn't very strong. > It just doesn't seem like a good name to me. It's a bit obscure and > we may want to do more things for hotplug later which may not fit the > param name. If you guys think it's good enough, please go ahead. > Thanks very much! I have addressed your comments and finish the v5 version. Please help checking them again after I send them to the community. Thanks.
On Tue, 2013-09-24 at 23:24 +0800, Zhang Yanfei wrote: > Hello tejun, > > On 09/24/2013 09:31 PM, Zhang Yanfei wrote: > >> This came up during earlier review but never was addressed. Is > >> > "movablenode" the right name? Shouldn't it be something which > >> > explicitly shows that it's to prepare for memory hotplug? Also, maybe > >> > the above param should generate warning if CONFIG_MOVABLE_NODE isn't > >> > enabled? > > hmmm...as for the option name, if this option is set, it means, the kernel > > could support the functionality that a whole node is the so called > > movable node, which only has ZONE MOVABLE zone in it. So we choose > > to name the parameter "movablenode". > > > > As for the warning, will add it. > > I am now preparing the v5 version. Only in this patch we haven't come to an > agreement. So as for the boot option name, after my explanation, do you still > have the objection? Or you could suggest a good name for us, that'll be > very thankful:) I do not think the granularity has to stay as a node, and this option does nothing to with other devices that may be included in a node. So, how about using "movablemem"? Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello toshi-san On 09/25/2013 12:00 AM, Toshi Kani wrote: > On Tue, 2013-09-24 at 23:24 +0800, Zhang Yanfei wrote: >> Hello tejun, >> >> On 09/24/2013 09:31 PM, Zhang Yanfei wrote: >>>> This came up during earlier review but never was addressed. Is >>>>> "movablenode" the right name? Shouldn't it be something which >>>>> explicitly shows that it's to prepare for memory hotplug? Also, maybe >>>>> the above param should generate warning if CONFIG_MOVABLE_NODE isn't >>>>> enabled? >>> hmmm...as for the option name, if this option is set, it means, the kernel >>> could support the functionality that a whole node is the so called >>> movable node, which only has ZONE MOVABLE zone in it. So we choose >>> to name the parameter "movablenode". >>> >>> As for the warning, will add it. >> >> I am now preparing the v5 version. Only in this patch we haven't come to an >> agreement. So as for the boot option name, after my explanation, do you still >> have the objection? Or you could suggest a good name for us, that'll be >> very thankful:) > > I do not think the granularity has to stay as a node, and this option > does nothing to with other devices that may be included in a node. So, > how about using "movablemem"? > As I explained before, we use movablenode to mean a node could only have a MOVABLE zone from the memory aspect. So I still think movablenode seems better than movablemem. movablemem seems vaguer here....
On Wed, 2013-09-25 at 00:08 +0800, Zhang Yanfei wrote: > Hello toshi-san > > On 09/25/2013 12:00 AM, Toshi Kani wrote: > > On Tue, 2013-09-24 at 23:24 +0800, Zhang Yanfei wrote: > >> Hello tejun, > >> > >> On 09/24/2013 09:31 PM, Zhang Yanfei wrote: > >>>> This came up during earlier review but never was addressed. Is > >>>>> "movablenode" the right name? Shouldn't it be something which > >>>>> explicitly shows that it's to prepare for memory hotplug? Also, maybe > >>>>> the above param should generate warning if CONFIG_MOVABLE_NODE isn't > >>>>> enabled? > >>> hmmm...as for the option name, if this option is set, it means, the kernel > >>> could support the functionality that a whole node is the so called > >>> movable node, which only has ZONE MOVABLE zone in it. So we choose > >>> to name the parameter "movablenode". > >>> > >>> As for the warning, will add it. > >> > >> I am now preparing the v5 version. Only in this patch we haven't come to an > >> agreement. So as for the boot option name, after my explanation, do you still > >> have the objection? Or you could suggest a good name for us, that'll be > >> very thankful:) > > > > I do not think the granularity has to stay as a node, and this option > > does nothing to with other devices that may be included in a node. So, > > how about using "movablemem"? > > > > As I explained before, we use movablenode to mean a node could only have > a MOVABLE zone from the memory aspect. So I still think movablenode seems > better than movablemem. movablemem seems vaguer here.... But a node may contain other devices, such CPUs and PCI bridges. To me, movablenode does not clarify that this option is from the memory aspect... Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1a036cd..8c056c4 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1769,6 +1769,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. that the amount of memory usable for all allocations is not too small. + movablenode [KNL,X86] This parameter enables/disables the + kernel to arrange hotpluggable memory ranges recorded + in ACPI SRAT(System Resource Affinity Table) as + ZONE_MOVABLE. And these memory can be hot-removed when + the system is up. + By specifying this option, all the hotpluggable memory + will be in ZONE_MOVABLE, which the kernel cannot use. + This will cause NUMA performance down. For users who + care about NUMA performance, just don't use it. + If all the memory ranges in the system are hotpluggable, + then the ones used by the kernel at early time, such as + kernel code and data segments, initrd file and so on, + won't be set as ZONE_MOVABLE, and won't be hotpluggable. + Otherwise the kernel won't have enough memory to boot. + MTD_Partition= [MTD] Format: <name>,<region-number>,<size>,<offset> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 36cfce3..2cf04fd 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1132,6 +1132,14 @@ void __init setup_arch(char **cmdline_p) early_acpi_boot_init(); initmem_init(); + + /* + * When ACPI SRAT is parsed, which is done in initmem_init(), + * set memblock back to the top-down direction. + */ + if (memblock_bottom_up()) + memblock_set_bottom_up(false); + memblock_find_dma_reserve(); /* diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index ed85fe3..9d36fee 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -31,6 +31,7 @@ #include <linux/firmware-map.h> #include <linux/stop_machine.h> #include <linux/hugetlb.h> +#include <linux/memblock.h> #include <asm/tlbflush.h> @@ -1386,6 +1387,32 @@ static bool can_offline_normal(struct zone *zone, unsigned long nr_pages) { return true; } + +static int __init cmdline_parse_movablenode(char *p) +{ + /* + * Memory used by the kernel cannot be hot-removed because Linux + * cannot migrate the kernel pages. When memory hotplug is + * enabled, we should prevent memblock from allocating memory + * for the kernel. + * + * ACPI SRAT records all hotpluggable memory ranges. But before + * SRAT is parsed, we don't know about it. + * + * The kernel image is loaded into memory at very early time. We + * cannot prevent this anyway. So on NUMA system, we set any + * node the kernel resides in as un-hotpluggable. + * + * Since on modern servers, one node could have double-digit + * gigabytes memory, we can assume the memory around the kernel + * image is also un-hotpluggable. So before SRAT is parsed, just + * allocate memory near the kernel image to try the best to keep + * the kernel away from hotpluggable memory. + */ + memblock_set_bottom_up(true); + return 0; +} +early_param("movablenode", cmdline_parse_movablenode); #else /* CONFIG_MOVABLE_NODE */ /* ensure the node has NORMAL memory if it is still online */ static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)