On Fri, Nov 20, 2020 at 4:28 AM Saeed Mirzamohammadi saeed.mirzamohammadi@oracle.com wrote:
Hi,
And I think crashkernel=auto could be used as an indicator that user want the kernel to control the crashkernel size, so some further work could be done to adjust the crashkernel more accordingly. eg. when memory encryption is enabled, increase the crashkernel value for the auto estimation, as it's known to consume more crashkernel memory.
Thanks for the suggestion! I tried to keep it simple and leave it to the user to change Kconfig in case a different range is needed. Based on experience, these ranges work well for most of the regular cases.
Yes, I think the current implementation is a very good start.
There are some use cases, where kernel is expected to reserve more memory, like: - when memory encryption is enabled, an extra swiotlb size of memory should be reserved - on pcc, fadump will expect more memory to be reserved
I believe there are a lot more cases like these. I tried to come up with some patches to let the kernel reserve more memory automatically, when such conditions are detected, but changing the crashkernel= specified value is really weird.
But if we have a crashkernel=auto, then kernel automatically reserve more memory will make sense.
But why not make it arch-independent? This crashkernel=auto idea should simply work with every arch.
Thanks! I’ll be making it arch-independent in the v2 patch.
#include <asm/page.h> #include <asm/sections.h> @@ -41,6 +42,15 @@ static int __init parse_crashkernel_mem(char *cmdline, unsigned long long *crash_base) { char *cur = cmdline, *tmp;
unsigned long long total_mem = system_ram;
/*
* Firmware sometimes reserves some memory regions for it's own use.
* so we get less than actual system memory size.
* Workaround this by round up the total size to 128M which is
* enough for most test cases.
*/
total_mem = roundup(total_mem, SZ_128M);
I think this rounding may be better moved to the arch specified part where parse_crashkernel is called?
Thanks for the suggestion. Could you please elaborate why do we need to do that?
Every arch gets their total memory value using different methods, (just check every parse_crashkernel call, and the system_ram param is filled in many different ways), so I'm really not sure if this rounding is always suitable.
Thanks, Saeed
-- Best Regards, Kairui Song