summaryrefslogtreecommitdiff
path: root/SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch
diff options
context:
space:
mode:
authorSentry <sentry@Sentry-Desktop-Fedora.local>2020-07-14 15:58:43 +0200
committerJan200101 <sentrycraft123@gmail.com>2020-12-05 19:40:07 +0100
commit391fe055c943e33e9c191dbeeb21995c0d54ccd9 (patch)
tree04bbfbe91a73cc0d47c2d70235c8ca365eaa9c3d /SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch
downloadkernel-fsync-391fe055c943e33e9c191dbeeb21995c0d54ccd9.tar.gz
kernel-fsync-391fe055c943e33e9c191dbeeb21995c0d54ccd9.zip
kernel 5.7.8
Diffstat (limited to 'SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch')
-rw-r--r--SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch189
1 files changed, 189 insertions, 0 deletions
diff --git a/SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch b/SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch
new file mode 100644
index 0000000..83eb38e
--- /dev/null
+++ b/SOURCES/0001-kdump-add-support-for-crashkernel-auto.patch
@@ -0,0 +1,189 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Jeremy Cline <jcline@redhat.com>
+Date: Tue, 23 Jul 2019 15:24:30 +0000
+Subject: [PATCH] kdump: add support for crashkernel=auto
+
+Rebased for v5.3-rc1 because the documentation has moved.
+
+ Message-id: <20180604013831.574215750@redhat.com>
+ Patchwork-id: 8166
+ O-Subject: [kernel team] [PATCH RHEL8.0 V2 2/2] kdump: add support for crashkernel=auto
+ Bugzilla: 1507353
+ RH-Acked-by: Don Zickus <dzickus@redhat.com>
+ RH-Acked-by: Baoquan He <bhe@redhat.com>
+ RH-Acked-by: Pingfan Liu <piliu@redhat.com>
+
+ Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1507353
+ Build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=16534135
+ Tested: ppc64le, x86_64 with several memory sizes.
+ kdump qe tested 160M on various x86 machines in lab.
+
+ We continue to provide crashkernel=auto like we did in RHEL6
+ and RHEL7, this will simplify the kdump deployment for common
+ use cases that kdump just works with the auto reserved values.
+ But this is still a best effort estimation, we can not know the
+ exact memory requirement because it depends on a lot of different
+ factors.
+
+ The implementation of crashkernel=auto is simplified as a wrapper
+ to use below kernel cmdline:
+ x86_64: crashkernel=1G-64G:160M,64G-1T:256M,1T-:512M
+ s390x: crashkernel=4G-64G:160M,64G-1T:256M,1T-:512M
+ arm64: crashkernel=2G-:512M
+ ppc64: crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G
+
+ The difference between this way and the old implementation in
+ RHEL6/7 is we do not scale the crash reserved memory size according
+ to system memory size anymore.
+
+ Latest effort to move upstream is below thread:
+ https://lkml.org/lkml/2018/5/20/262
+ But unfortunately it is still unlikely to be accepted, thus we
+ will still use a RHEL only patch in RHEL8.
+
+ Copied old patch description about the history reason see below:
+ '''
+ Non-upstream explanations:
+ Besides "crashkenrel=X@Y" format, upstream also has advanced
+ "crashkernel=range1:size1[,range2:size2,...][@offset]", and
+ "crashkernel=X,high{low}" formats, but they need more careful
+ manual configuration, and have different values for different
+ architectures.
+
+ Most of the distributions use the standard "crashkernel=X@Y"
+ upstream format, and use crashkernel range format for advanced
+ scenarios, heavily relying on the user's involvement.
+
+ While "crashkernel=auto" is redhat's special feature, it exists
+ and has been used as the default boot cmdline since 2008 rhel6.
+ It does not require users to figure out how many crash memory
+ size for their systems, also has been proved to be able to work
+ pretty well for common scenarios.
+
+ "crashkernel=auto" was tested/based on rhel-related products, as
+ we have stable kernel configurations which means more or less
+ stable memory consumption. In 2014 we tried to post them again to
+ upstream but NACKed by people because they think it's not general
+ and unnecessary, users can specify their own values or do that by
+ scripts. However our customers insist on having it added to rhel.
+
+ Also see one previous discussion related to this backport to Pegas:
+ On 10/17/2016 at 10:15 PM, Don Zickus wrote:
+ > On Fri, Oct 14, 2016 at 10:57:41AM +0800, Dave Young wrote:
+ >> Don, agree with you we should evaluate them instead of just inherit
+ >> them blindly. Below is what I think about kdump auto memory:
+ >> There are two issues for crashkernel=auto in upstream:
+ >> 1) It will be seen as a policy which should not go to kernel
+ >> 2) It is hard to get a good number for the crash reserved size,
+ >> considering various different kernel config options one can setups.
+ >> In RHEL we are easier because our supported Kconfig is limited.
+ >> I digged the upstream mail archive, but I'm not sure I got all the
+ >> information, at least Michael Ellerman was objecting the series for
+ >> 1).
+ > Yes, I know. Vivek and I have argued about this for years. :-)
+ >
+ > I had hoped all the changes internally to the makedumpfile would allow
+ > the memory configuration to stabilize at a number like 192M or 128M and
+ > only in the rare cases extend beyond that.
+ >
+ > So I always treated that as a temporary hack until things were better.
+ > With the hope of every new RHEL release we get smarter and better. :-)
+ > Ideally it would be great if we could get the number down to 64M for most
+ > cases and just turn it on in Fedora. Maybe someday.... ;-)
+ >
+ > We can have this conversation when the patch gets reposted/refreshed
+ > for upstream on rhkl?
+ >
+ > Cheers,
+ > Don
+
+ We had proposed to drop the historic crashkernel=auto code and move
+ to use crashkernel=range:size format and pass them in anaconda.
+
+ The initial reason is crashkernel=range:size works just fine because
+ we do not need complex algorithm to scale crashkernel reserved size
+ any more. The old linear scaling is mainly for old makedumpfile
+ requirements, now it is not necessary.
+
+ But With the new approach, backward compatibility is potentially at risk.
+ For e.g. let's consider the following cases:
+ 1) When we upgrade from an older distribution like rhel-alt-7.4(which
+ uses crashkernel=auto) to rhel-alt-7.5 (which uses the crashkernel=xY
+ format)
+ In this case we can use anaconda scripts for checking
+ 'crashkernel=auto' in kernel spec and update to the new
+ 'crashkernel=range:size' format.
+ 2) When we upgrade from rhel-alt-7.5(which uses crashkernel=xY format)
+ to rhel-alt-7.6(which uses crashkernel=xY format), but the x and/or Y
+ values are changed in rhel-alt-7.6.
+ For example from crashkernel=2G-:160M to crashkernel=2G-:192M, then we have
+ no way to determine if the X and/or Y values were distribution
+ provided or user specified ones.
+ Since it is recommended to give precedence to user-specified values,
+ so we cannot do an upgrade in such a case."
+
+ Thus turn back to resolve it in kernel, and add a simpler version
+ which just hacks to use the range:size style in code, and make
+ rhel-only code easily to maintain.
+ '''
+
+ Signed-off-by: Dave Young <dyoung@redhat.com>
+ Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
+
+Upstream Status: RHEL only
+Signed-off-by: Jeremy Cline <jcline@redhat.com>
+---
+ Documentation/admin-guide/kdump/kdump.rst | 11 +++++++++++
+ kernel/crash_core.c | 14 ++++++++++++++
+ 2 files changed, 25 insertions(+)
+
+diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
+index ac7e131d2935..3b3bf30e537d 100644
+--- a/Documentation/admin-guide/kdump/kdump.rst
++++ b/Documentation/admin-guide/kdump/kdump.rst
+@@ -285,6 +285,17 @@ 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 if you have enough memory. The threshold
++is 2G on x86_64, arm64, ppc64 and ppc64le. The threshold is 4G for s390x.
++If your system memory is less than the threshold crashkernel=auto will not
++reserve memory.
++
++The automatically reserved memory size varies based on architecture.
++The size changes according to system memory size like below:
++ x86_64: 1G-64G:160M,64G-1T:256M,1T-:512M
++ s390x: 4G-64G:160M,64G-1T:256M,1T-:512M
++ arm64: 2G-:512M
++ ppc64: 2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G
+
+
+ Boot into System Kernel
+diff --git a/kernel/crash_core.c b/kernel/crash_core.c
+index d631d22089ba..c252221b2f4b 100644
+--- a/kernel/crash_core.c
++++ b/kernel/crash_core.c
+@@ -258,6 +258,20 @@ static int __init __parse_crashkernel(char *cmdline,
+ if (suffix)
+ return parse_crashkernel_suffix(ck_cmdline, crash_size,
+ suffix);
++
++ if (strncmp(ck_cmdline, "auto", 4) == 0) {
++#ifdef CONFIG_X86_64
++ ck_cmdline = "1G-64G:160M,64G-1T:256M,1T-:512M";
++#elif defined(CONFIG_S390)
++ ck_cmdline = "4G-64G:160M,64G-1T:256M,1T-:512M";
++#elif defined(CONFIG_ARM64)
++ ck_cmdline = "2G-:512M";
++#elif defined(CONFIG_PPC64)
++ ck_cmdline = "2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G";
++#endif
++ pr_info("Using crashkernel=auto, the size choosed is a best effort estimation.\n");
++ }
++
+ /*
+ * if the commandline contains a ':', then that's the extended
+ * syntax -- if not, it must be the classic syntax
+--
+2.26.2
+