Eric W. Biederman wrote:
Sure, I have no plan to do growing reserved memory at run-time... only freeing or shrinking it...Amerigo Wang <amwang@xxxxxxxxxx> writes:Yes, exactly, in fact I am doing another part which will allow us to take back of the reserved memory at run-time.Alright. Let's look at that. I would make the restriction you can't resize the area while a kexec on panic image is loaded, and growing the area would not be a realistic option.
If crash_kernel=auto happens in the context of being able to shrink the area from user space the definition is simple. We reserve as much memory as we think we can without affecting performance, stability, reliability. We can use an initial approximation of perhaps 1/32nd of low memory (aka directly mapped memory), and I don't see a point in making the code arch dependent at all. We should run the size approximation past the folks on linux-mm as they are more likely to know how much memory reduction we can tolerate without problems.
Yup, agreed.
We can then plan on user space saying hey that is more than I need: shrink that, and load the kexec on panic kernel.
Exactly... but the interface still needs to be discussed... Currently, we have two options: 1) add a new flag to kexec_load(2) to tell the kernel to shrink the memory;2) use /proc/iomem, let the user to decide which and how much of the reserved memory should be removed.
Any thoughts? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |