If the way adding default value into kernel config is disliked,
this a) option looks good. We can get value with x% of system RAM, but
clamp it with CRASH_KERNEL_MIN/MAX. The CRASH_KERNEL_MIN/MAX may need be
defined with a default value for different ARCHes. It's very close to
our current implementation, and handling 'auto' in kernel.
And kernel config provided so that people can tune the MIN/MAX value,
but no need to post patch to do the tuning each time if have to?
Maybe I'm missing something, but the whole point is to avoid kernel
configuration option at all. If the crashkernel=auto works good for 99% of
the cases, there is no need to provide build time configuration along with
it. There are plenty of ways users can control crashkernel reservations
with the existing 2-4 (depending on architecture) command line options.
Simply hard coding a reasonable defaults (e.g.
"1G-64G:128M,64G-1T:256M,1T-:512M"), and using these defaults when
crashkernel=auto is set would cover the same 99% of users you referred to.
Right, and we can easily allocate a bit more as a safety net temporarily
when we can actually shrink the area later.
If we can resize the reservation later during boot this will also address
David's concern about the wasted memory.
Yes.
You mentioned that amount of memory that is required for crash kernel
reservation depends on the devices present on the system. Is is possible to
detect how much memory is required at late stages of boot?
Here is my thinking:
There seems to be some kind of formula we can roughly use to come up
with the final crashkernel size. Baoquan for sure knows all the dirty
details, I assume it's roughly "core kernel + drivers + user space".
In the kernel, we can only come up with "core kernel + drivers"
expecting that we will run
a) roughly the same kernel
b) with roughly the same drivers
The "user space" part is completely under user space control, depending
on what application will be run after kexec.
So I wonder if something like
crashkernel=auto,100M
whereby "100M" corresponds to user space demands in addition to the
variable part depend on the current kernel + drivers.
would already be somewhat sufficient for main use cases I guess.
Of course, that approach will get more complicated if the user space
portion heavily depends on the drivers etc. Then we need more tunables.
--
Thanks,
David / dhildenb
