Re: [patch 48/91] kernel/crash_core: add crashkernel=auto for vmcore creation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/07/21 at 10:16am, David Hildenbrand wrote:
> On 07.05.21 03:04, Andrew Morton wrote:
......
> > 
> >   Documentation/admin-guide/kdump/kdump.rst       |    3 +-
> >   Documentation/admin-guide/kernel-parameters.txt |    6 ++++
> >   arch/Kconfig                                    |   20 ++++++++++++++
> >   kernel/crash_core.c                             |    7 ++++
> >   4 files changed, 35 insertions(+), 1 deletion(-)
> > 
> > --- a/arch/Kconfig~kernel-crash_core-add-crashkernel=auto-for-vmcore-creation
> > +++ a/arch/Kconfig
> > @@ -14,6 +14,26 @@ menu "General architecture-dependent opt
> >   config CRASH_CORE
> >   	bool
> > +config CRASH_AUTO_STR
> > +	string "Memory reserved for crash kernel"
> > +	depends on CRASH_CORE
> > +	default "1G-64G:128M,64G-1T:256M,1T-:512M"
> > +	help
> > +	  This configures the reserved memory dependent
> > +	  on the value of System RAM. The syntax is:
> > +	  crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
> > +	              range=start-[end]
> > +
> > +	  For example:
> > +	      crashkernel=512M-2G:64M,2G-:128M
> > +
> > +	  This would mean:
> > +
> > +	      1) if the RAM is smaller than 512M, then don't reserve anything
> > +	         (this is the "rescue" case)
> > +	      2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
> > +	      3) if the RAM size is larger than 2G, then reserve 128M
> > +
> >   config KEXEC_CORE
> >   	select CRASH_CORE
> >   	bool
> > --- a/Documentation/admin-guide/kdump/kdump.rst~kernel-crash_core-add-crashkernel=auto-for-vmcore-creation
> > +++ a/Documentation/admin-guide/kdump/kdump.rst
> > @@ -285,7 +285,8 @@ This would mean:
> >       2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
> >       3) if the RAM size is larger than 2G, then reserve 128M
> > -
> > +Or you can use crashkernel=auto to choose the crash kernel memory size
> > +based on the recommended configuration set for each arch.
> >   Boot into System Kernel
> >   =======================
> > --- a/Documentation/admin-guide/kernel-parameters.txt~kernel-crash_core-add-crashkernel=auto-for-vmcore-creation
> > +++ a/Documentation/admin-guide/kernel-parameters.txt
> > @@ -751,6 +751,12 @@
> >   			a memory unit (amount[KMG]). See also
> >   			Documentation/admin-guide/kdump/kdump.rst for an example.
> > +	crashkernel=auto
> > +			[KNL] This parameter will set the reserved memory for
> > +			the crash kernel based on the value of the CRASH_AUTO_STR
> > +			that is the best effort estimation for each arch. See also
> > +			arch/Kconfig for further details.
> > +
> >   	crashkernel=size[KMG],high
> >   			[KNL, X86-64] range could be above 4G. Allow kernel
> >   			to allocate physical memory region from top, so could
> > --- a/kernel/crash_core.c~kernel-crash_core-add-crashkernel=auto-for-vmcore-creation
> > +++ a/kernel/crash_core.c
> > @@ -7,6 +7,7 @@
> >   #include <linux/crash_core.h>
> >   #include <linux/utsname.h>
> >   #include <linux/vmalloc.h>
> > +#include <linux/kexec.h>
> >   #include <asm/page.h>
> >   #include <asm/sections.h>
> > @@ -250,6 +251,12 @@ static int __init __parse_crashkernel(ch
> >   	if (suffix)
> >   		return parse_crashkernel_suffix(ck_cmdline, crash_size,
> >   				suffix);
> > +#ifdef CONFIG_CRASH_AUTO_STR
> > +	if (strncmp(ck_cmdline, "auto", 4) == 0) {
> > +		ck_cmdline = CONFIG_CRASH_AUTO_STR;
> > +		pr_info("Using crashkernel=auto, the size chosen is a best effort estimation.\n");
> > +	}
> > +#endif
> I remember that the original "crashkernel=auto" as once proposed by Red Hat
> people did not receive a warm welcome.
> 
> Let me take a look .... oh, there it is from 2009
> 
> https://marc.info/?t=125006512600002&r=1&w=2
> 
> and then we had it in 2018
> 
> https://lkml.org/lkml/2018/5/20/262

Thanks for digging these two out, otherwise I may need do for people to
know the history better.

> 
> 
> The issue I have with this: it's just plain wrong when you take memory
> hotplug into serious account as we see it quite heavily in VMs. You don't
> know what you'll need when building a kernel. Just pass it via the cmdline

Hmm, kdump may have no issue with memory hotplug in crashkernel
reservation aspect. The system RAM size is not correlated to
crashkernel size directly, that's why the default value in this patch is
not linear related to system RAM size. The proportion of crashkernel
size to the total RAM size is thing we take into account. Usually
crashkernel 160M is enough on most of systems. If system RAM size is
larger, extra memory can be added just in case, and not bring much
impact to system.

With our investigation, PCIe devices impact the crashkernel size, and
cpu number. There are always pci devices which driver require tens of KB
meomry, even MB. E.g in below patch, my colleague Coiby found out the
i40e network card even cost 1.5G memory to initialize its ringbuffer on
ppc, and 85M on x86_64.

[PATCH v1 0/3] Reducing memory usage of i40e for kdump
http://lists.infradead.org/pipermail/kexec/2021-March/022117.html

Even though not all pci devices need surprisingly large memory like
i40e, system with hundreds of pci devices can also cost more memory than
expected. This kind of system usually is high end server, specified
crashkernel value need be set manually. 

So system RAM size is the least important part to influence crashkernel
costing. Say my x1 laptop, even though I extended the RAM to 100TB, 160M
crashkernel is still enough. Just we would like to get a tiny extra part
to add to crashkernel if the total RAM is very large, that's the rule
for crashkernel=auto. As for VMs, given their very few devices, virtio
disk, NAT nic, etc, no matter how much memory is deployed and hot
added/removed, crashkernel size won't be influenced very much. My
personal understanding about it.

Thanks
Baoquan




[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux