On 06/23/2016 05:20 AM, Ronit halder wrote:
Currently, linux kernel allocates memory at the boot time for crash
kernel booted using kexec system call in kernel crash. It will be very
useful if we can allocate memory in run time. The user can get more
usable RAM if we can do that.
What kind of memory savings are you expecting here? I'm interested in
an answer of the form "currently kexec takes X MB with this approach
it can go down to Y MB"
It is possible to allocate memory for crash kernel at the boot time
using CMA (Contiguous Memory Allocator). CMA is capable of allocating
big chunk of memory. At the boot time we will create one (if only low
memory is used) or two (if we use both high and low memory) CMA areas
of size given in "crashkernel" boot time command line parameter. This
memory in CMA areas can be used by movable pages (used for disk caches,
process pages, etc) if not allocated. Then the user can allocate or
free memory from those CMA areas using "/sys/kernel/kexec_crash_size"
sysfs entry. If the user uses high memory kernel will automatically at
least 256MB low memory when the user allocates memory using mentioned
sysfs enrty. In case of high memory allocation the user controls the
size of reserved region in high memory with
"/sys/kernel/kexec_crash_size" entry. If the size set is zero then the
memory allocated in low memory will automatically be freed.
I am attaching a prototype patch with the mail. Please share your
opinions on my approach. This patch is only for x86 and x86_64.
Please note, this patch is only a prototype just to explain my approach
and get the review.
Is calling kexec_crash_size a requirement to do kexec? If not, it seems
like there could be a code path where the CMA memory never actually gets
How are you evaluating the reliability of CMA? The migration that backs
CMA is not guaranteed to succeed, especially if it's a precisely sized
You mentioned that this code is only for x86 right now but it seems like
other arches that implement CMA (arm, arm64, powerpc) could benefit
as well. Try to come up with a way this can be used on other arches.
Signed-off-by: Ronit Halder <ronit.crj(a)gmail.com>
kernel mailing list