I can understand the reasoning of "using a fraction of the memory size" when
booting up just to be on the safe side as we don't know", and that
motivation is much better than what I read so far. But then I wonder if we
cannot handle that any better? Because this feels very suboptimal to me and
I feel like there can be cases where the heuristic is just wrong.
Yes, I understand what you said. Our headache is mainly from bare metal
system worrying the reservation is not enough becuase of many devices.
On VM, it is truly different. With much less devices, it does waste some
memory. Usually a fixed minimal size can cover 99.9% of system unless
too many devices attached/added to VM, I am not sure what's the
probability it could happen. While, by the help of /sys/kernel/kexec_crash_size,
you can shrink it to an small enough but available size. Just you may
need to reload kdump kernel because the loaded kernel should have been
erazed and out of control. The shrinking should be done at early stage of
kernel running, I would say, lest crash may happen during that period.
We ever tried several different ways to enlarge the crashkernel size
dynamically, but didn't think of a good way.
Yes, enlarging it at runtime much more difficult than shrinking.
[...]
A kernel early during boot can only guess. A kernel late during boot knows.
Please correct me if I'm wrong.
Well, I would not say it's guess, and would like to call them experical
values from statistical data. With a priori vlaue given by 'auto',
basically normal users of kdump don't need to care about the setting.
E.g on Fedora, 'auto' can cover all systems, assume nobody would deploy
it on a high end server. Everything we do is to make thing simple enough.
If you don't know how to set, just add 'crashkernel=auto' to cmdline,
then everything is done. I believe you agree that not everybody would
like to dig into kexec/kdump just for getting how big crashkernel size
need be set when they want to use kdump functionality.
Oh absolutely. But OTOH, most users will leave the value untouched if it
works -- and complain at least in the VM environment to me about
surpises waste of system RAM with "crashkernel=auto".
[...]
I know how helpful "crashkernel=auto" was so far, but I am also aware that
there was strong pushback in the past, and I remember for the reasons I
gave. IMHO we should refine that approach instead of trying to push the same
thing upstream every couple of years.
I ran into the "512MB crashkernel" on a 64G VM with memory ballooning issue
already but didn't report a BZ, because so far, I was under the impression
that more memory means more crashkernel. But you explained to me that I was
just running into a (for my use case) bad heuristic.
I re-read the old posts, didn't see strong push-back. People just gave
some different ideas instead. When we were silent, we tried different
way, e.g the enlarging crashkernel at run time as told at above, but
failed. Reusing free pages and user space pages of 1st kernel in kdump
kernel, also failed. We also talked with people to consult if it's
Thanks for an insight into the history.
doable to remove 'auto' support, nobody would like to give an affirmative
answer. I know SUSE is using the way you mentioned to get a recommended
size for long time, but it needs severeal more steps and need reboot. We
prefer to take that way too as an improvement. The simpler, the better.
At least I'm happy to hear that other people had the same idea as me ;)
I can understand the desire for simplicity. it would be great to hear
SUSEs perception of the problem and how they would ideally want to move
forward with this.
[...]
I'll be happy to help looking into dynamic shrinking of the crashkernel size
if that approach makes sense. We could even let user space trigger that
resizing -- without a reboot.
Don't reply each inline comment since I believe they have been covered
by the earlier reply. Thanks for looking to this and telling your
thought, to let us know that in fact you really care about the extra
memory on VMs which we have realized, but didn't realized it really cause
issue.
I mess with dynamic resizing of VMs, that's why I usually take a closer
look at all things that do stuff based on the initial VM size; yes,
there is still a lot other such things out there.
It also bugged me for quite a bit that we don't have a sane way to
achieve what we're doing here upstream. It somewhat feels like "this
doesn't belong in the kernel and is user policy" but then, the existing
kernel support is suboptimal.
Maybe reserving some "maybe too big but okayish to boot the system in a
sane environment -- e.g., X% of system RAM and at least Y" size first
and shrinking it later as triggered by user space early (where we do
seem to have a way to pre-calculate things now) might actually be a good
direction to look into.
--
Thanks,
David / dhildenb
