On Wed, Dec 01, 2021 at 06:15:07PM +0800, Kairui Song wrote:
Coiby Xu <coxu(a)redhat.com> 于2021年11月19日周五 上午11:24写道:
>
> The crashkernel=auto implementation in kernel space has been rejected
> upstream [1]. The current user space implementation [2] [3] ships a
> crashkernel.default but hasn't supported the swiotlb memory requirement,
> custom crashkernel value from user and fadump.
>
> The crashkernel.default implementation seems to be overly
> complex,
> - the default crashkernel value rarely changes. This is no need to ship
> the same crashkernel.default default for every kernel package of a
> architecture;
> - when deciding the value of crashkernel for a new kernel, the
> crashkernel.default of existing kernel is took into consideration
>
> We can simply let the kexec-tools maintain the default crashkernel
> values and provide an API for kdump-anacon-addon to query it. And for
> a newly installed kernel, we can simply call "kdumpctl reset-crashkernel
> KERNELPATH" to set its crashkernel value.
>
> For the unfulfilled requirements,
> - crashkernel is introduced to /etc/kdump.conf for
the user can set
> custom crashkernel value to tell kexec-tools to
manage crashkernel
> value automatically.
> - "kdumpctl reset-crashkernel" has been
written for the above
> purpose.
> - "kdumpctl fadump on/off" is added for
supporting fadump.
>
>
> [1]
https://lore.kernel.org/linux-mm/20210507010432.IN24PudKT%25akpm@linux-fo...
> [2]
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171
> [3]
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...
>
Nice idea👍, this makes thing so much cleaner.
Thanks for endorsing this idea!
I remember the per version crashkernel.default file is introduced for
many purposes in mind.
For example a new kernel package may enabled/disabled something so it
will need a larger/smaller crashkernel value, or, eg. a variant
kernel, like debug kernel, can set itself a larger value.
I have been wondering why you ship a crashkernel.default with a kernel
package, debug kernel could be one of the reasons. But kdump memory
requirement could change dynamically. For example, the user could toggle
SME on/off. So a static crashkernel couldn't address this dynamic
change. On the other hand, we should be able to tell if a kernel is a
debug kernel or has something enabled/disabled in kexec-tools. So my idea
is the default crashkernel value could act as a baseline value and we
will increase/decrease the crashernel value dynamically after evaluating
different cases in kexec-tools. Btw, do you have a list of how different
factors affect the memory requirement? The list may look like this,
1. debug kernel: need to increase the default crashkernel value by 30%
2. SME: an extra memory of 64MB at maximum
3. kernel config option CONFIG_XXX: 100MB+
4. ...
And one can easily distinguish if the actual used crashkernel value
is
the default value of a specified kernel version, even cross OS
upgrade.
I guess these cases are finally considered too rare to be covered?
Decoupling it from kernel version definitely saves tons of trouble
(which was almost killing me :D).
>
> Coiby Xu (11):
> update default crashkernel value
> factor out kdump_get_arch_recommend_crashkernel
> provide get_default_crashkernel for kdump_anaconda_addon
> introduce crashkernel option to kdump.conf
> add a helper function to write a config value to kdump.conf
> add a helper function to read kernel cmdline parameter from grubby
> --info
> rewrite reset_crashkernel to provide more features for the user and to
> be called by kernel installation hook
> allow to add extra memory to crashkernel string
> Reserve extra memory when SME or SEV is active
> provide kdumpctl fadump on/off
> use "kdumpctl reset-crashkernel KERNELIMAGE" in kernel installation
> hook
>
> 92-crashkernel.install | 135 +----------------------------
> kdump-lib-initramfs.sh | 9 ++
> kdump-lib.sh | 95 +++++++++++++++------
> kdump.conf | 6 ++
> kdump.conf.5 | 7 ++
> kdumpctl | 188 ++++++++++++++++++++++++++++++++++++-----
> kdumpctl.8 | 16 ++--
> 7 files changed, 271 insertions(+), 185 deletions(-)
>
> --
> 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 on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
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 on the list, report it:
https://pagure.io/fedora-infrastructure
--
Best regards,
Coiby