Re: [RFC] proposal for run time memory allocation for crash kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 23, 2016 at 1:06 PM, Laura Abbott <labbott@xxxxxxxxxx> wrote:
> 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"
No, it doesn't save any memory. It just adds the flexibility to select
size of reserved memory for crash kernel at run time. That way the
user allocate the memory when he needs it and the size he want (size
should be less than the size of CMA area). The current approach in
linux allocates this memory at boot time. The memory requirement
varies depends on the size of chosen crash kernel.
>
>> 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
> allocated.
Yes, it is necessary.
>
> 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
> area.
>
There there is no guarantee. It fails.
> 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@xxxxxxxxx>
>>
>>
>>
>> _______________________________________________
>> kernel mailing list
>> kernel@xxxxxxxxxxxxxxxxxxxxxxx
>> https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
>>
>
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux