On Fri, 3 Dec 2021 21:05:11 +0800
Kairui Song <ryncsn(a)gmail.com> wrote:
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.
@Kairui: Nice to see you active on the mailing list :)
> 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).
Actually this is something I was pondering on in the last few days,
too. My trigger was looking at patch 9 from this series as it is adding
the extra memory for SEV only when setting crashkernel= but not when
estimating it. On the other hand do_estimate does consider some cases
(like the memory required for encrypted targets) that are missing in
reset_kernel. So I started thinking about how those two cases but
couldn't find a proper solution yet.
The main problem I see is that 'estimate' and 'reset-crashkernel' run
in completely different environments. Especially 'reset-crashkernel' is
supposed to run during the installation of a kernel which leads to some
problems. For example there is no dump initramfs created yet and it
might not be possible to create one as the currently running kernel and
the one that is installed might require different modules.
So the "perfect" solution might need to look something like this
1) boot system to run updates
2) reboot new kernel to estimate and set crashkernel=
2b) reboot for slow path (optional)
3) reboot to make use of new crashkernel= value
and that every time when installing a new kernel, which I don't think
is reasonable.
That's where I'm stuck at the moment...
Thanks
Philipp
> 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
>
_______________________________________________
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