Coiby Xu <coxu(a)redhat.com> 于 2021年12月3日周五 下午6:00写道:
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.
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,
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. ...
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(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
>