Hi Jiri, I'd really love to see something like this to work. Although I also share the concerns about shitty device drivers corrupting the CMA. Please see my other mail for that. Anyway, one more comment below. On Fri, 24 Nov 2023 20:54:36 +0100 Jiri Bohac <jbohac@xxxxxxx> wrote: [...] > Now, specifying > crashkernel=100M craskhernel=1G,cma > on the command line will make a standard crashkernel reservation > of 100M, where kexec will load the kernel and initrd. > > An additional 1G will be reserved from CMA, still usable by the > production system. The crash kernel will have 1.1G memory > available. The 100M can be reliably predicted based on the size > of the kernel and initrd. I doubt that the fixed part can be predicted "reliably". For sure it will be more reliable than today but IMHO we will still be stuck with some guessing. Otherwise it would mean that you already know during boot which initrd the user space will be loading later on. Which IMHO is impossible as the initrd can always be rebuild with a larger size. Furthermore, I'd be careful when you are dealing with compressed kernel images. As I'm not sure how the different decompressor phases would handle scenarios where the (fixed) crashkernel memory is large enough to hold the compressed kernel (+initrd) but not the decompressed one. One more thing, I'm not sure I like that you need to reserve two separate memory regions. Personally I would prefer it if you could reserve one large region for the crashkernel but allow parts of it to be reused via CMA. Otherwise I'm afraid there will be people who only have one ,cma entry on the command line and cannot figure out why they cannot load the crash kernel. Thanks Philipp > When no crashkernel=size,cma is specified, everything works as > before. > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
