Re: [PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
On Wed, 2013-09-25 at 02:34 +0800, Zhang Yanfei wrote: > From: Tang Chen > > Memory reserved for crashkernel could be large. So we should not allocate > this memory bottom up from the end of kernel image. > > When SRAT is parsed, we will be able to know whihc memory is hotpluggable, > and we can avoid allocating this memory for the kernel. So reorder > reserve_crashkernel() after SRAT is parsed. > > Acked-by: Tejun Heo > Signed-off-by: Tang Chen > Reviewed-by: Zhang Yanfei > --- > arch/x86/kernel/setup.c |8 ++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index f0de629..36cfce3 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -1120,8 +1120,6 @@ void __init setup_arch(char **cmdline_p) > acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start); > #endif > > - reserve_crashkernel(); > - > vsmp_init(); > > io_delay_init(); > @@ -1136,6 +1134,12 @@ void __init setup_arch(char **cmdline_p) > initmem_init(); > memblock_find_dma_reserve(); > > + /* > + * Reserve memory for crash kernel after SRAT is parsed so that it > + * won't consume hotpluggable memory. > + */ > + reserve_crashkernel(); Out of curiosity, is there any particular reason why it is moved after memblock_find_dma_reserve(), not initmem_init()? Thanks, -Toshi -- 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: [PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
On Wed, 2013-09-25 at 02:34 +0800, Zhang Yanfei wrote: From: Tang Chen tangc...@cn.fujitsu.com Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image. When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed. Acked-by: Tejun Heo t...@kernel.org Signed-off-by: Tang Chen tangc...@cn.fujitsu.com Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com --- arch/x86/kernel/setup.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index f0de629..36cfce3 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1120,8 +1120,6 @@ void __init setup_arch(char **cmdline_p) acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start); #endif - reserve_crashkernel(); - vsmp_init(); io_delay_init(); @@ -1136,6 +1134,12 @@ void __init setup_arch(char **cmdline_p) initmem_init(); memblock_find_dma_reserve(); + /* + * Reserve memory for crash kernel after SRAT is parsed so that it + * won't consume hotpluggable memory. + */ + reserve_crashkernel(); Out of curiosity, is there any particular reason why it is moved after memblock_find_dma_reserve(), not initmem_init()? Thanks, -Toshi -- 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: [PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
On 09/26/2013 10:49 PM, Tejun Heo wrote: > On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote: >> From: Tang Chen >> >> Memory reserved for crashkernel could be large. So we should not allocate >> this memory bottom up from the end of kernel image. >> >> When SRAT is parsed, we will be able to know whihc memory is hotpluggable, >> and we can avoid allocating this memory for the kernel. So reorder >> reserve_crashkernel() after SRAT is parsed. >> >> Acked-by: Tejun Heo > > So, I was hoping to hear from you on how you tested it when I wrote > the previous comment - the "provided..." part. > This function is actually used for kexec/kdump. So After applying this patch, booting the kernel, this reservation is successful and the kdump service starts successfully. Thanks. -- Thanks. Zhang Yanfei -- 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: [PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote: > From: Tang Chen > > Memory reserved for crashkernel could be large. So we should not allocate > this memory bottom up from the end of kernel image. > > When SRAT is parsed, we will be able to know whihc memory is hotpluggable, > and we can avoid allocating this memory for the kernel. So reorder > reserve_crashkernel() after SRAT is parsed. > > Acked-by: Tejun Heo So, I was hoping to hear from you on how you tested it when I wrote the previous comment - the "provided..." part. -- tejun -- 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: [PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote: From: Tang Chen tangc...@cn.fujitsu.com Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image. When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed. Acked-by: Tejun Heo t...@kernel.org So, I was hoping to hear from you on how you tested it when I wrote the previous comment - the provided... part. -- tejun -- 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: [PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
On 09/26/2013 10:49 PM, Tejun Heo wrote: On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote: From: Tang Chen tangc...@cn.fujitsu.com Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image. When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed. Acked-by: Tejun Heo t...@kernel.org So, I was hoping to hear from you on how you tested it when I wrote the previous comment - the provided... part. This function is actually used for kexec/kdump. So After applying this patch, booting the kernel, this reservation is successful and the kdump service starts successfully. Thanks. -- Thanks. Zhang Yanfei -- 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/
[PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
From: Tang Chen Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image. When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed. Acked-by: Tejun Heo Signed-off-by: Tang Chen Reviewed-by: Zhang Yanfei --- arch/x86/kernel/setup.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index f0de629..36cfce3 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1120,8 +1120,6 @@ void __init setup_arch(char **cmdline_p) acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start); #endif - reserve_crashkernel(); - vsmp_init(); io_delay_init(); @@ -1136,6 +1134,12 @@ void __init setup_arch(char **cmdline_p) initmem_init(); memblock_find_dma_reserve(); + /* +* Reserve memory for crash kernel after SRAT is parsed so that it +* won't consume hotpluggable memory. +*/ + reserve_crashkernel(); + #ifdef CONFIG_KVM_GUEST kvmclock_init(); #endif -- 1.7.1 -- 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/
[PATCH v5 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed
From: Tang Chen tangc...@cn.fujitsu.com Memory reserved for crashkernel could be large. So we should not allocate this memory bottom up from the end of kernel image. When SRAT is parsed, we will be able to know whihc memory is hotpluggable, and we can avoid allocating this memory for the kernel. So reorder reserve_crashkernel() after SRAT is parsed. Acked-by: Tejun Heo t...@kernel.org Signed-off-by: Tang Chen tangc...@cn.fujitsu.com Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com --- arch/x86/kernel/setup.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index f0de629..36cfce3 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1120,8 +1120,6 @@ void __init setup_arch(char **cmdline_p) acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start); #endif - reserve_crashkernel(); - vsmp_init(); io_delay_init(); @@ -1136,6 +1134,12 @@ void __init setup_arch(char **cmdline_p) initmem_init(); memblock_find_dma_reserve(); + /* +* Reserve memory for crash kernel after SRAT is parsed so that it +* won't consume hotpluggable memory. +*/ + reserve_crashkernel(); + #ifdef CONFIG_KVM_GUEST kvmclock_init(); #endif -- 1.7.1 -- 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/
