On 05/24/18 at 03:26pm, Dave Young wrote: > On 05/24/18 at 08:57am, Petr Tesarik wrote: > > On Thu, 24 May 2018 09:49:05 +0800 > > Dave Young <dyoung@xxxxxxxxxx> wrote: > > > > > Hi Petr, > > > > > > On 05/23/18 at 10:22pm, Petr Tesarik wrote: > > >[...] > > > > In short, if one size fits none, what good is it to hardcode that "one > > > > size" into the kernel image? > > > > > > I agreed with all the things that we can not know the exact memory > > > requirement for 100% use cases. But that does not means this is useless > > > it is still useful for common use cases of no special and memory hog > > > requirements as I mentioned in another reply it can simplify the kdump > > > deployment for those people who do not need the special setup. > > > > I still tend to disagree. This "common-case" reservation depends on > > things that are defined by user space. It surely does not make it > > easier to build a distribution kernel. Today, I get bug reports that > > the number calculated and added to the boot loader configuration by the > > installer is inaccurate. If I put a fixed number into a kernel config > > option, I will start getting bugs that this number is incorrect (for > > some systems). > > The value is a best effort, it will never be 100% correct. We did not > guarantee that. The kernel config option value is just up to user. > So I'm thinking it as a good to have benefit. I means this patch is not trying to force add a fixed value for crashkernel in kernel code. It provides another way one can use on kernel build time the value just works. > > > > > > For example, if this is a workstation I just want to break into a shell > > > to collect some panic info, then I just need a very minimal initrd, then > > > the Kconfig will work just fine. > > > > What is "a very minimal initrd"? Last time I had to make a significant > > adjustment to the estimation for openSUSE, this was caused by growing > > user-space requirements (systemd in this case, but I don't want to > > start flamewars on that topic, please). > > Still I think we have agreement and same feeling about the userspace > memory requirement. I think although it is hard, we have been still > trying to shrink the initramfs memory use. > > Besides of distribution use, why people can not use some minimal > initrd? For example only a basic shell and some necessary tools and > basic storage eg. raw disks supported, and he/she can just collect the > panic infomation by himself in a shell. > > > > > Anyway, if you want to improve the "common case", then look how IBM > > tries to solve it for firmware-assisted dump (fadump) on powerpc: > > > > https://patchwork.ozlabs.org/patch/905026/ > > > > The main idea is: > > > > > Instead of setting aside a significant chunk of memory nobody can use, > > > [...] reserve a significant chunk of memory that the kernel is prevented > > > from using [...], but applications are free to use it. > > > > That works great, because user space pages are filtered out in the > > common case, so they can be used freely by the panic kernel. > > Good suggestion. I have been reading that posts already at the same time before I saw > this reply from you :) > > That could be a good idea and worth to discuss more. I cced Hari > already in the thread. Hari, is it possible for you to extend your > idea to general use, ie. shared by both kdump and fadump? Anyway I > think that is another topic we can discuss separately. > > > > > Just my two cents, > > Petr T > > Thanks > Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
