| Message ID | 5241DB3A.6090002@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, Sep 25, 2013 at 02:34:34AM +0800, Zhang Yanfei wrote: > From: Tang Chen <tangchen@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 <tj@kernel.org> So, I was hoping to hear from you on how you tested it when I wrote the previous comment - the "provided..." part.
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 <tangchen@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 <tj@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.
On Wed, 2013-09-25 at 02:34 +0800, Zhang Yanfei wrote: > From: Tang Chen <tangchen@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 <tj@kernel.org> > Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com> > Reviewed-by: Zhang Yanfei <zhangyanfei@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-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/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