Coiby Xu coxu@redhat.com 于 2021年12月3日周五 下午6:00写道：
On Wed, Dec 01, 2021 at 06:15:07PM +0800, Kairui Song wrote:
Coiby Xu coxu@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-found... [2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171 [3] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/...
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.
Hi, thanks for the reply.
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.
That's absolutely correct, kernel itself isn't capable of estimating the crashkernel value. And actually crashkernel.default wasn't suppose to play the sole role on deciding the final crashkernel value.
Userspace have the ultimate right and more capable of estimating and deciding the crashkernel value.
i was planning previously, that crashkernel value decision will be composed of two parts: - kernel's crashkernel.default value as a reference. - kexec-tools do some estimation and adjust based on the kernel value.
This way both kernel and kexec-tools package have a say on deciding the final crashkernel value.
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.
I totally agree, I originally wanted to enhance the "kdumpctl estimate", it will have two ways of estimating:
- Fast path: according to data collectable in first kernel (including the crashkernel.default file). - Slow path: do a actually kdump and collect info during the kdump run. It need at least one reboot, which will be really slow on some big servers, it's an unanswered question if this really worth it.
Then kexec-tools can suggest, or even set the crashkernel based on the estimating. But it's undecided how the two different estimating will play together on deciding the final crashkernel value. Maybe keep using the value estimated by fast path unless user manually triggers a slow path run. (And the slow path run will be invalided after kernel upgrade, so again not sure if user will really like it, maybe just focus on development of the fast path estimate is simpler).
Btw, do you have a list of how different factors affect the memory requirement? The list may look like this,
- debug kernel: need to increase the default crashkernel value by 30%
- SME: an extra memory of 64MB at maximum
- kernel config option CONFIG_XXX: 100MB+
- ...
I'm afraid no, it's really hard to make a table about the memory effect of each kernel component/feature.
You may need to do tons of experiments and testing to get the data, and in most time, a kenrel debug/feature config only consume a little part of the memory but a lot of such configs are enabled.
And these memory usage data will change from time to time as kernel updates, and some CONFIG combination will have more complex memory effect pattern... so I thought a crashkernel.default file set based on experience is preferred, and more doable.
This whole approach may need some simplification, eg. previously I was avoiding adding a new method of customizing crashkernel value, so grubby will still be user's first choice on customizing the crashkernel value. Grubby and the instal.d hook will take care of the management of crashkernel value, but this made the hook doing a lot of complex work. This patch adding a new config in kdump.conf, is just much cleaner, and I definitely like this more.
Maybe like you said, use the .default file as a baseline, and let kexec-tools maintain the actual value, then just cover some known cases, will be better idea. Other works can get respinned later.
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@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