2:07 a.m.
On aarch64, both 4K and 64K kernel can be installed, while they demand
different size reserved memory for kdump kernel.
'get_conf PAGE_SIZE' can not work if installing a 64K kernel when
running a 4K kernel. Hence resorting to the kernel release naming rules.
At present, the 64K kernel has the keyword '64k' in its suffix.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdump-lib.sh | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh
index 6b0a83d..d5d13bc 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -908,6 +908,7 @@ get_recommend_size()
# get default crashkernel
# $1 dump mode, if not specified, dump_mode will be judged by is_fadump_capable
+# $2 kernel-release, if not specified, got by 'uname -r'
kdump_get_arch_recommend_crashkernel()
{
local _arch _ck_cmdline _dump_mode
@@ -927,8 +928,21 @@ kdump_get_arch_recommend_crashkernel()
if [[ $_arch == "x86_64" ]] || [[ $_arch == "s390x" ]]; then
_ck_cmdline="1G-4G:192M,4G-64G:256M,64G-:512M"
elif [[ $_arch == "aarch64" ]]; then
- # For 4KB page size, the formula is based on x86 plus extra = 64M
- _ck_cmdline="1G-4G:256M,4G-64G:320M,64G-:576M"
+ local _running_kernel
+
+ if [[ -z "$2" ]]; then
+ _running_kernel=$(uname -r)
+ else
+ _running_kernel=$2
+ fi
+
+ if echo "$_running_kernel" | grep 64k; then
+ # For 64KB page size
+ _ck_cmdline="2G-:480M"
+ else
+ # For 4KB page size, the formula is based on x86 plus extra = 64M
+ _ck_cmdline="1G-4G:256M,4G-64G:320M,64G-:576M"
+ fi
elif [[ $_arch == "ppc64le" ]]; then
if [[ $_dump_mode == "fadump" ]]; then
_ck_cmdline="4G-16G:768M,16G-64G:1G,64G-128G:2G,128G-1T:4G,1T-2T:6G,2T-4T:12G,4T-8T:20G,8T-16T:36G,16T-32T:64G,32T-64T:128G,64T-:180G"
--
2.31.1
2:07 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K kernel
Here comes the requirement of the 64K aarch64 kernel.
The typical user case is: the anaconda installs the 4K kernel and later,
if a user needs 64K kernel, he/she need to install it separatedly.
Since the 4K kernel has a different memory reservation from the 64K, the
new installed 64K kernel can use the recommended value regardless of the
user defined value for 4K kernel.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdumpctl | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/kdumpctl b/kdumpctl
index 553c392..e43fab7 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1623,6 +1623,7 @@ reset_crashkernel_for_installed_kernel()
{
local _installed_kernel _running_kernel _crashkernel _crashkernel_running
local _dump_mode_running _fadump_val_running
+ local _arch
# During package install, only try to reset crashkernel for osbuild
# thus to avoid calling grubby when installing os via anaconda
@@ -1651,6 +1652,29 @@ reset_crashkernel_for_installed_kernel()
_dump_mode_running=$(get_dump_mode_by_kernel "$_running_kernel")
_fadump_val_running=$(get_grub_kernel_boot_parameter "$_kernel" fadump)
+ _arch=$(uname -m)
+ # On aarch64, there are 4K and 64K kernel, which demands different crashkernel value
+ if [[ $_arch == "aarch64" ]]; then
+ local _installed_64K _running_64K
+
+ _installed_64K=0
+ #echo "$_installed_kernel" | grep 64k
+ if echo "$_installed_kernel" | grep 64k; then
+ _installed_64K=1
+ fi
+ if echo "$_running_kernel" | grep 64k; then
+ _running_64K=1
+ fi
+
+ # Otherwise, fall through to common case
+ if [[ $_installed_64K != "$_running_64K" ]]; then
+ # if the difference is 4K VS 64K
+ _crashkernel_running=$(kdump_get_arch_recommend_crashkernel "kdump"
"$_installed_kernel")
+ _update_kernel_cmdline "$_installed_kernel"
"$_crashkernel_running" "$_dump_mode_running"
"$_fadump_val_running"
+ return
+ fi
+ fi
+
if [[ $_crashkernel != "$_crashkernel_running" ]]; then
if _update_kernel_cmdline "$_installed_kernel"
"$_crashkernel_running" "$_dump_mode_running"
"$_fadump_val_running"; then
echo "kexec-tools has reset $_installed_kernel to use the new default crashkernel
value $_crashkernel_running"
--
2.31.1
2:20 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K kernel
On Fri, Feb 10, 2023 at 4:08 PM Pingfan Liu <piliu(a)redhat.com> wrote:
Here comes the requirement of the 64K aarch64 kernel.
The typical user case is: the anaconda installs the 4K kernel and later,
if a user needs 64K kernel, he/she need to install it separatedly.
Since the 4K kernel has a different memory reservation from the 64K, the
new installed 64K kernel can use the recommended value regardless of the
user defined value for 4K kernel.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdumpctl | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/kdumpctl b/kdumpctl
index 553c392..e43fab7 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1623,6 +1623,7 @@ reset_crashkernel_for_installed_kernel()
{
local _installed_kernel _running_kernel _crashkernel _crashkernel_running
local _dump_mode_running _fadump_val_running
+ local _arch
# During package install, only try to reset crashkernel for osbuild
# thus to avoid calling grubby when installing os via anaconda
@@ -1651,6 +1652,29 @@ reset_crashkernel_for_installed_kernel()
_dump_mode_running=$(get_dump_mode_by_kernel "$_running_kernel")
_fadump_val_running=$(get_grub_kernel_boot_parameter "$_kernel"
fadump)
+ _arch=$(uname -m)
+ # On aarch64, there are 4K and 64K kernel, which demands different crashkernel
value
+ if [[ $_arch == "aarch64" ]]; then
+ local _installed_64K _running_64K
+
+ _installed_64K=0
+ #echo "$_installed_kernel" | grep 64k
+ if echo "$_installed_kernel" | grep 64k; then
+ _installed_64K=1
+ fi
+ if echo "$_running_kernel" | grep 64k; then
+ _running_64K=1
+ fi
+
+ # Otherwise, fall through to common case
+ if [[ $_installed_64K != "$_running_64K" ]]; then
+ # if the difference is 4K VS 64K
+ _crashkernel_running=$(kdump_get_arch_recommend_crashkernel
"kdump" "$_installed_kernel")
Here, if the installed kernel is different from the running kernel, it
just uses the default recommended "crashkernel=".
But when discussion with Coiby off-list, he showed his concerns:
-1. whether it is suitable to use the default recommended 64K value if
a user has a user defined value for 4K kernel
-2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
'4K_a ', the user has specify his prefered "crashkernel=", and in
64K_b, during the installation of 4K_c kernel, this patch can not
inherit the user preferred value for 4K_a.
(where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
three instances a, b and c.)
For the time being, I have no good idea about it. Any suggestions about it?
Thanks,
Pingfan
+ _update_kernel_cmdline
"$_installed_kernel" "$_crashkernel_running"
"$_dump_mode_running" "$_fadump_val_running"
+ return
+ fi
+ fi
+
if [[ $_crashkernel != "$_crashkernel_running" ]]; then
if _update_kernel_cmdline "$_installed_kernel"
"$_crashkernel_running" "$_dump_mode_running"
"$_fadump_val_running"; then
echo "kexec-tools has reset $_installed_kernel to use the
new default crashkernel value $_crashkernel_running"
--
2.31.1
_______________________________________________
kexec mailing list -- kexec(a)lists.fedoraproject.org
To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
12:37 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K kernel
+Philipp and Baoquan,
Could you share any opinion/suggestion about it?
Thanks
On Fri, Feb 10, 2023 at 4:20 PM Pingfan Liu <piliu(a)redhat.com> wrote:
On Fri, Feb 10, 2023 at 4:08 PM Pingfan Liu <piliu(a)redhat.com> wrote:
>
> Here comes the requirement of the 64K aarch64 kernel.
>
> The typical user case is: the anaconda installs the 4K kernel and later,
> if a user needs 64K kernel, he/she need to install it separatedly.
>
> Since the 4K kernel has a different memory reservation from the 64K, the
> new installed 64K kernel can use the recommended value regardless of the
> user defined value for 4K kernel.
>
> Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
> ---
> kdumpctl | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/kdumpctl b/kdumpctl
> index 553c392..e43fab7 100755
> --- a/kdumpctl
> +++ b/kdumpctl
> @@ -1623,6 +1623,7 @@ reset_crashkernel_for_installed_kernel()
> {
> local _installed_kernel _running_kernel _crashkernel _crashkernel_running
> local _dump_mode_running _fadump_val_running
> + local _arch
>
> # During package install, only try to reset crashkernel for osbuild
> # thus to avoid calling grubby when installing os via anaconda
> @@ -1651,6 +1652,29 @@ reset_crashkernel_for_installed_kernel()
> _dump_mode_running=$(get_dump_mode_by_kernel "$_running_kernel")
> _fadump_val_running=$(get_grub_kernel_boot_parameter "$_kernel"
fadump)
>
> + _arch=$(uname -m)
> + # On aarch64, there are 4K and 64K kernel, which demands different
crashkernel value
> + if [[ $_arch == "aarch64" ]]; then
> + local _installed_64K _running_64K
> +
> + _installed_64K=0
> + #echo "$_installed_kernel" | grep 64k
> + if echo "$_installed_kernel" | grep 64k; then
> + _installed_64K=1
> + fi
> + if echo "$_running_kernel" | grep 64k; then
> + _running_64K=1
> + fi
> +
> + # Otherwise, fall through to common case
> + if [[ $_installed_64K != "$_running_64K" ]]; then
> + # if the difference is 4K VS 64K
> + _crashkernel_running=$(kdump_get_arch_recommend_crashkernel
"kdump" "$_installed_kernel")
Here, if the installed kernel is different from the running kernel, it
just uses the default recommended "crashkernel=".
But when discussion with Coiby off-list, he showed his concerns:
-1. whether it is suitable to use the default recommended 64K value if
a user has a user defined value for 4K kernel
-2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
'4K_a ', the user has specify his prefered "crashkernel=", and in
64K_b, during the installation of 4K_c kernel, this patch can not
inherit the user preferred value for 4K_a.
(where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
three instances a, b and c.)
For the time being, I have no good idea about it. Any suggestions about it?
Thanks,
Pingfan
> + _update_kernel_cmdline "$_installed_kernel"
"$_crashkernel_running" "$_dump_mode_running"
"$_fadump_val_running"
> + return
> + fi
> + fi
> +
> if [[ $_crashkernel != "$_crashkernel_running" ]]; then
> if _update_kernel_cmdline "$_installed_kernel"
"$_crashkernel_running" "$_dump_mode_running"
"$_fadump_val_running"; then
> echo "kexec-tools has reset $_installed_kernel to use
the new default crashkernel value $_crashkernel_running"
> --
> 2.31.1
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
9:16 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and
64K kernel
Hi Pingfan,
Hi Coiby,
On Fri, 10 Feb 2023 16:20:27 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
[...]
Here, if the installed kernel is different from the running kernel,
it
just uses the default recommended "crashkernel=".
But when discussion with Coiby off-list, he showed his concerns:
-1. whether it is suitable to use the default recommended 64K value if
a user has a user defined value for 4K kernel
-2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
'4K_a ', the user has specify his prefered "crashkernel=", and in
64K_b, during the installation of 4K_c kernel, this patch can not
inherit the user preferred value for 4K_a.
(where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
three instances a, b and c.)
For the time being, I have no good idea about it. Any suggestions about it?
That's a valid point...
The way I see it we need to find a way to (1) split the problem into
smaller, easier digestible chunks and (2) define a way the user tells
us to manage the crashkernel value and thus allows us to ignore any
changes made manually.
The idea I'm having is that we split the crashkernel default value and
the update routines from the main kexec-tools into a separate package.
Ideally we even find a way to define different versions of that package
that depend on a specific kernel version/variant. When a user installs
this package he/she also agrees that we are managing the crashkernel
parameter and allows us to overwrite any changes made by the user.
The idea is still pretty vague, but I think it is worth thinking about
if splitting up the kexec-tools package can help simplifying the
problem.
Thanks
Philipp
1:29 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K
kernel
Hi Philipp and Pingfan,
On Tue, Feb 14, 2023 at 04:16:25PM +0100, Philipp Rudo wrote:
Hi Pingfan,
Hi Coiby,
On Fri, 10 Feb 2023 16:20:27 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
[...]
> Here, if the installed kernel is different from the running kernel, it
> just uses the default recommended "crashkernel=".
>
> But when discussion with Coiby off-list, he showed his concerns:
> -1. whether it is suitable to use the default recommended 64K value if
> a user has a user defined value for 4K kernel
> -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
> '4K_a ', the user has specify his prefered "crashkernel=", and in
> 64K_b, during the installation of 4K_c kernel, this patch can not
> inherit the user preferred value for 4K_a.
> (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
> three instances a, b and c.)
>
> For the time being, I have no good idea about it. Any suggestions about it?
That's a valid point...
The way I see it we need to find a way to (1) split the problem into
smaller, easier digestible chunks and (2) define a way the user tells
us to manage the crashkernel value and thus allows us to ignore any
changes made manually.
The idea I'm having is that we split the crashkernel default value and
the update routines from the main kexec-tools into a separate package.
Ideally we even find a way to define different versions of that package
that depend on a specific kernel version/variant. When a user installs
this package he/she also agrees that we are managing the crashkernel
parameter and allows us to overwrite any changes made by the user.
The idea is still pretty vague, but I think it is worth thinking about
if splitting up the kexec-tools package can help simplifying the
problem.
Thanks for sharing your idea!
We only use default crashkernel for new kernel or update default
crashkernel for existing kernels when
1) auto_reset_crashkernel=yes
2) current running kernel use default crashkernel or the-be-updated
kernel use old default crashkernel
One big complexity is to address the 2nd condition. Considering we
have different default crashkernel values for different kernels on the
same system for the cases of kdump/fadump and 4k/64k kernels, I'd like
to propose to write the default crashkernel value to
/var/lib/kdump/crashkernel/KERNEL_NVR for each kernel that uses default
crashkernel so
a) when we need to update the default crashkernel value for existing
kernels, we read its /var/lib/kdump/crashkernel/KERNEL_NVR and compare
it with the value it's using now
b) when we need to set up the crashkernel parameter for newly-installed
kernel, we read /var/lib/kdump/crashkernel/KERNEL_NVR of default kernel
(grubby --info=DEFAULT) and compare the value with the value that the
default kernel is using now
Thanks
Philipp
--
Best regards,
Coiby
12:11 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K kernel
Hi Coiby,
On Wed, Feb 15, 2023 at 3:31 PM Coiby Xu <coxu(a)redhat.com> wrote:
Hi Philipp and Pingfan,
On Tue, Feb 14, 2023 at 04:16:25PM +0100, Philipp Rudo wrote:
>Hi Pingfan,
>Hi Coiby,
>
>
>On Fri, 10 Feb 2023 16:20:27 +0800
>Pingfan Liu <piliu(a)redhat.com> wrote:
>
>[...]
>
>> Here, if the installed kernel is different from the running kernel, it
>> just uses the default recommended "crashkernel=".
>>
>> But when discussion with Coiby off-list, he showed his concerns:
>> -1. whether it is suitable to use the default recommended 64K value if
>> a user has a user defined value for 4K kernel
>> -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
>> '4K_a ', the user has specify his prefered "crashkernel=", and
in
>> 64K_b, during the installation of 4K_c kernel, this patch can not
>> inherit the user preferred value for 4K_a.
>> (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
>> three instances a, b and c.)
>>
>> For the time being, I have no good idea about it. Any suggestions about it?
>
>That's a valid point...
>
>The way I see it we need to find a way to (1) split the problem into
>smaller, easier digestible chunks and (2) define a way the user tells
>us to manage the crashkernel value and thus allows us to ignore any
>changes made manually.
>
>The idea I'm having is that we split the crashkernel default value and
>the update routines from the main kexec-tools into a separate package.
>Ideally we even find a way to define different versions of that package
>that depend on a specific kernel version/variant. When a user installs
>this package he/she also agrees that we are managing the crashkernel
>parameter and allows us to overwrite any changes made by the user.
>
>The idea is still pretty vague, but I think it is worth thinking about
>if splitting up the kexec-tools package can help simplifying the
>problem.
Thanks for sharing your idea!
We only use default crashkernel for new kernel or update default
crashkernel for existing kernels when
1) auto_reset_crashkernel=yes
2) current running kernel use default crashkernel or the-be-updated
kernel use old default crashkernel
One big complexity is to address the 2nd condition. Considering we
have different default crashkernel values for different kernels on the
same system for the cases of kdump/fadump and 4k/64k kernels, I'd like
to propose to write the default crashkernel value to
/var/lib/kdump/crashkernel/KERNEL_NVR for each kernel that uses default
crashkernel so
a) when we need to update the default crashkernel value for existing
kernels, we read its /var/lib/kdump/crashkernel/KERNEL_NVR and compare
it with the value it's using now
b) when we need to set up the crashkernel parameter for newly-installed
kernel, we read /var/lib/kdump/crashkernel/KERNEL_NVR of default kernel
(grubby --info=DEFAULT) and compare the value with the value that the
default kernel is using now
I prefer this direction.
But what about the user defined value? Currently "/etc/kernel/cmdline"
can only hold a valid user defined value for a kernel variant. Hence I
think besides the default value for different kernel variants, we also
need two places to hold different user defined values. Unfortunately,
this is beyond the scope of kexec-tools? Or kexec-tools can introduce
another file "/etc/kernel/cmdline.64K", and add comments at the head
of "/etc/kernel/cmdline" to remind the user.
Thanks,
Pingfan
6:46 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K
kernel
Hi Pingfan, Philipp,
On 02/14/23 at 04:16pm, Philipp Rudo wrote:
Hi Pingfan,
Hi Coiby,
On Fri, 10 Feb 2023 16:20:27 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
[...]
For the 64K arm64 kernel installation itself and this patchset, I am
wondering:
1) If we check the NVR of kernel and decide if it's 64K or 4K, it only
works for formal arm64 kernel rpm, right? Some brew build kernel, or
self built kernel won't get handled correctly?
> Here, if the installed kernel is different from the running kernel, it
> just uses the default recommended "crashkernel=".
>
> But when discussion with Coiby off-list, he showed his concerns:
> -1. whether it is suitable to use the default recommended 64K value if
> a user has a user defined value for 4K kernel
> -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
> '4K_a ', the user has specify his prefered "crashkernel=", and in
> 64K_b, during the installation of 4K_c kernel, this patch can not
> inherit the user preferred value for 4K_a.
> (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
> three instances a, b and c.)
>
> For the time being, I have no good idea about it. Any suggestions about it?
2) For Coiby's concern, if thing is easy to handle, we would like to see
4K_c inherit value from 4K_a. Aside from the technical detail, this
looks more natural, but not strong opinion if not easy to implement. While
I personally would suggest we don't need to make it perfectly one time,
just an available one, we can polish it later. Maybe one day we decide
to go in a different way, E.g see Philipp's suggestion or something else?
That's a valid point...
The way I see it we need to find a way to (1) split the problem into
smaller, easier digestible chunks and (2) define a way the user tells
us to manage the crashkernel value and thus allows us to ignore any
changes made manually.
The idea I'm having is that we split the crashkernel default value and
the update routines from the main kexec-tools into a separate package.
Ideally we even find a way to define different versions of that package
that depend on a specific kernel version/variant. When a user installs
this package he/she also agrees that we are managing the crashkernel
parameter and allows us to overwrite any changes made by the user.
The idea is still pretty vague, but I think it is worth thinking about
if splitting up the kexec-tools package can help simplifying the
problem.
Yeah, we may need think about simplifying in a whole view. Imagine we
pull a not heavy stuff as before, but now it become harder and harder,
we'd better check if we put the pulling rope on our shoulder, but not
around neck. Just a soft opinion in a view, it's surely not urgent, we
can consider this sometimes.
2:05 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K kernel
Hi Baoquan,
Thanks for sharing your ideas. Please see inline comments below.
On Wed, Feb 15, 2023 at 8:46 PM Baoquan He <bhe(a)redhat.com> wrote:
Hi Pingfan, Philipp,
On 02/14/23 at 04:16pm, Philipp Rudo wrote:
> Hi Pingfan,
> Hi Coiby,
>
>
> On Fri, 10 Feb 2023 16:20:27 +0800
> Pingfan Liu <piliu(a)redhat.com> wrote:
>
> [...]
For the 64K arm64 kernel installation itself and this patchset, I am
wondering:
1) If we check the NVR of kernel and decide if it's 64K or 4K, it only
works for formal arm64 kernel rpm, right? Some brew build kernel, or
self built kernel won't get handled correctly?
Yes, the self built kernel is a challenge but hard to handle. Suppose
that building and installing a 64K kernel on a 4K kernel. For this
case, it may have a lower priority until we figure it out.
>
> > Here, if the installed kernel is different from the running kernel, it
> > just uses the default recommended "crashkernel=".
> >
> > But when discussion with Coiby off-list, he showed his concerns:
> > -1. whether it is suitable to use the default recommended 64K value if
> > a user has a user defined value for 4K kernel
> > -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
> > '4K_a ', the user has specify his prefered "crashkernel=",
and in
> > 64K_b, during the installation of 4K_c kernel, this patch can not
> > inherit the user preferred value for 4K_a.
> > (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
> > three instances a, b and c.)
> >
> > For the time being, I have no good idea about it. Any suggestions about it?
2) For Coiby's concern, if thing is easy to handle, we would like to see
4K_c inherit value from 4K_a. Aside from the technical detail, this
Agree, and it is practicable.
looks more natural, but not strong opinion if not easy to implement.
While
I personally would suggest we don't need to make it perfectly one time,
just an available one, we can polish it later. Maybe one day we decide
to go in a different way, E.g see Philipp's suggestion or something else?
>
> That's a valid point...
>
> The way I see it we need to find a way to (1) split the problem into
> smaller, easier digestible chunks and (2) define a way the user tells
> us to manage the crashkernel value and thus allows us to ignore any
> changes made manually.
>
> The idea I'm having is that we split the crashkernel default value and
> the update routines from the main kexec-tools into a separate package.
> Ideally we even find a way to define different versions of that package
> that depend on a specific kernel version/variant. When a user installs
> this package he/she also agrees that we are managing the crashkernel
> parameter and allows us to overwrite any changes made by the user.
>
> The idea is still pretty vague, but I think it is worth thinking about
> if splitting up the kexec-tools package can help simplifying the
> problem.
Yeah, we may need think about simplifying in a whole view. Imagine we
pull a not heavy stuff as before, but now it become harder and harder,
we'd better check if we put the pulling rope on our shoulder, but not
around neck. Just a soft opinion in a view, it's surely not urgent, we
can consider this sometimes.
Yes. And I think at present, the main concern is around the
maintenance e.g upgrading.
Thanks,
Pingfan
11:46 p.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and 64K kernel
Hi Philipp,
Thanks for your insight.
On Tue, Feb 14, 2023 at 11:17 PM Philipp Rudo <prudo(a)redhat.com> wrote:
Hi Pingfan,
Hi Coiby,
On Fri, 10 Feb 2023 16:20:27 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
[...]
> Here, if the installed kernel is different from the running kernel, it
> just uses the default recommended "crashkernel=".
>
> But when discussion with Coiby off-list, he showed his concerns:
> -1. whether it is suitable to use the default recommended 64K value if
> a user has a user defined value for 4K kernel
> -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
> '4K_a ', the user has specify his prefered "crashkernel=", and in
> 64K_b, during the installation of 4K_c kernel, this patch can not
> inherit the user preferred value for 4K_a.
> (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
> three instances a, b and c.)
>
> For the time being, I have no good idea about it. Any suggestions about it?
That's a valid point...
The way I see it we need to find a way to (1) split the problem into
smaller, easier digestible chunks and (2) define a way the user tells
us to manage the crashkernel value and thus allows us to ignore any
changes made manually.
The idea I'm having is that we split the crashkernel default value and
the update routines from the main kexec-tools into a separate package.
Ideally we even find a way to define different versions of that package
that depend on a specific kernel version/variant. When a user installs
this package he/she also agrees that we are managing the crashkernel
parameter and allows us to overwrite any changes made by the user.
I guess you suggest kexec-tools.aarch64_4K and kexec-tools.aarch64_64K.
But shall we consider the case in which a user needs two kernel
variants? If it is true, things may not easy.
Thanks,
Pingfan
4:53 a.m.
New subject: [PATCH 2/2] kdumpctl: add support for co-existence of 4K and
64K kernel
Hi Pingfan,
On Thu, 16 Feb 2023 13:46:30 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
Hi Philipp,
Thanks for your insight.
On Tue, Feb 14, 2023 at 11:17 PM Philipp Rudo <prudo(a)redhat.com> wrote:
>
> Hi Pingfan,
> Hi Coiby,
>
>
> On Fri, 10 Feb 2023 16:20:27 +0800
> Pingfan Liu <piliu(a)redhat.com> wrote:
>
> [...]
>
> > Here, if the installed kernel is different from the running kernel, it
> > just uses the default recommended "crashkernel=".
> >
> > But when discussion with Coiby off-list, he showed his concerns:
> > -1. whether it is suitable to use the default recommended 64K value if
> > a user has a user defined value for 4K kernel
> > -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
> > '4K_a ', the user has specify his prefered "crashkernel=",
and in
> > 64K_b, during the installation of 4K_c kernel, this patch can not
> > inherit the user preferred value for 4K_a.
> > (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
> > three instances a, b and c.)
> >
> > For the time being, I have no good idea about it. Any suggestions about it?
>
> That's a valid point...
>
> The way I see it we need to find a way to (1) split the problem into
> smaller, easier digestible chunks and (2) define a way the user tells
> us to manage the crashkernel value and thus allows us to ignore any
> changes made manually.
>
> The idea I'm having is that we split the crashkernel default value and
> the update routines from the main kexec-tools into a separate package.
> Ideally we even find a way to define different versions of that package
> that depend on a specific kernel version/variant. When a user installs
> this package he/she also agrees that we are managing the crashkernel
> parameter and allows us to overwrite any changes made by the user.
>
I guess you suggest kexec-tools.aarch64_4K and kexec-tools.aarch64_64K.
Not exactly. My idea was to split the kexec-tools into two packages,
i.e. the base kexec-tools containing most of todays package and
kexec-tools-crashkernel-default only handling the default values.
kexec-tools-crsahkernel-default could then be variant specific (if that
works).
But shall we consider the case in which a user needs two kernel
variants? If it is true, things may not easy.
Yeah, this would be a very nasty corner case with my suggestion...
Thanks
Philipp
429
days inactive
435
days old
10 comments
4 participants
participants (4)
-
Baoquan He -
Coiby Xu -
Philipp Rudo -
Pingfan Liu