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
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense to you I'm fine with it. I'd just recommend to test recent kernels in multiple distros with the minimum "range" to see if 64M is enough for crashkernel, maybe we'd need to bump that. Cheers,
Guilherme
Hi Guilherme, On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense to you I'm fine with it. I'd just recommend to test recent kernels in multiple distros with the minimum "range" to see if 64M is enough for crashkernel, maybe we'd need to bump that.
Giving the different kernel configs and the different userspace initramfs setup it is hard to get an uniform value for all distributions, but we can have an interface/kconfig-option for them to provide a value like this patch is doing. And it could be improved like Kairui said about some known kernel added extra values later, probably some more improvements if doable.
Thanks Dave
On 11/22/20 9:47 PM, Dave Young wrote:
Hi Guilherme, On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense to you I'm fine with it. I'd just recommend to test recent kernels in multiple distros with the minimum "range" to see if 64M is enough for crashkernel, maybe we'd need to bump that.
Giving the different kernel configs and the different userspace initramfs setup it is hard to get an uniform value for all distributions, but we can have an interface/kconfig-option for them to provide a value like this patch is doing. And it could be improved like Kairui said about some known kernel added extra values later, probably some more improvements if doable.
Thanks Dave
Hi.
Are we going to move forward with implementing this for X86 and Arm ?
If other platform maintainers want to include this CONFIG option in their configuration settings they have a starting point.
Thank you,
John.
( I am not currently on many of the included dist lists in this email, so hopefully key contributors are included in this exchange )
Hi John,
On 01/21/21 at 09:32am, john.p.donnelly@oracle.com wrote:
On 11/22/20 9:47 PM, Dave Young wrote:
Hi Guilherme, On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense to you I'm fine with it. I'd just recommend to test recent kernels in multiple distros with the minimum "range" to see if 64M is enough for crashkernel, maybe we'd need to bump that.
Giving the different kernel configs and the different userspace initramfs setup it is hard to get an uniform value for all distributions, but we can have an interface/kconfig-option for them to provide a value like this patch is doing. And it could be improved like Kairui said about some known kernel added extra values later, probably some more improvements if doable.
Thanks Dave
Hi.
Are we going to move forward with implementing this for X86 and Arm ?
If other platform maintainers want to include this CONFIG option in their configuration settings they have a starting point.
I would expect this become arch independent.
Saeed, Kairui, would any of you like to update the patch?
Thank you,
John.
( I am not currently on many of the included dist lists in this email, so hopefully key contributors are included in this exchange )
Thanks Dave
On 01/22/21 at 09:22am, Dave Young wrote:
Hi John,
On 01/21/21 at 09:32am, john.p.donnelly@oracle.com wrote:
On 11/22/20 9:47 PM, Dave Young wrote:
Hi Guilherme, On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense to you I'm fine with it. I'd just recommend to test recent kernels in multiple distros with the minimum "range" to see if 64M is enough for crashkernel, maybe we'd need to bump that.
Giving the different kernel configs and the different userspace initramfs setup it is hard to get an uniform value for all distributions, but we can have an interface/kconfig-option for them to provide a value like this patch is doing. And it could be improved like Kairui said about some known kernel added extra values later, probably some more improvements if doable.
Thanks Dave
Hi.
Are we going to move forward with implementing this for X86 and Arm ?
If other platform maintainers want to include this CONFIG option in their configuration settings they have a starting point.
I would expect this become arch independent.
Clarify a bit, it can be a general config option under arch/Kconfig and just put the code in general arch independent part.
Saeed, Kairui, would any of you like to update the patch?
Thank you,
John.
( I am not currently on many of the included dist lists in this email, so hopefully key contributors are included in this exchange )
Thanks Dave
linux-stable-mirror@lists.linaro.org
-
Dave Young -
Guilherme Piccoli -
john.p.donnelly＠oracle.com -
Kairui Song