[PATCH] kexec: add resriction on the kexec_load
Dave Young
dyoung at redhat.com
Thu Jul 21 01:10:49 PDT 2016
On 07/19/16 at 09:07pm, Eric W. Biederman wrote:
> zhongjiang <zhongjiang at huawei.com> writes:
>
> > From: zhong jiang <zhongjiang at huawei.com>
> >
> > I hit the following question when run trinity in my system. The
> > kernel is 3.4 version. but the mainline have same question to be
> > solved. The root cause is the segment size is too large, it can
> > expand the most of the area or the whole memory, therefore, it
> > may waste an amount of time to abtain a useable page. and other
> > cases will block until the test case quit. at the some time,
> > OOM will come up.
>
> 5MiB is way too small. I have seen vmlinux images not to mention
> ramdisks that get larger than that. Depending on the system
> 1GiB might not be an unreasonable ramdisk size. AKA run an entire live
> system out of a ramfs. It works well if you have enough memory.
There was a use case from Michael Holzheu about a 1.5G ramdisk, see below
kexec-tools commit:
commit 95741713e790fa6bde7780bbfb772ad88e81a744
Author: Michael Holzheu <holzheu at linux.vnet.ibm.com>
Date: Fri Oct 30 16:02:04 2015 +0100
kexec/s390x: use mmap instead of read for slurp_file()
The slurp_fd() function allocates memory and uses the read() system
call.
This results in double memory consumption for image and initrd:
1) Memory allocated in user space by the kexec tool
2) Memory allocated in kernel by the kexec() system call
The following illustrates the use case that we have on s390x:
1) Boot a 4 GB Linux system
2) Copy kernel and 1,5 GB ramdisk from external source into tmpfs
(ram)
3) Use kexec to boot kernel with ramdisk
Therefore for kexec runtime we need:
1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) =
4,5 GB
This patch introduces slurp_file_mmap() which for "normal" files
uses
mmap() instead of malloc()/read(). This reduces the runtime memory
consumption of the kexec tool as follows:
1,5 GB (tmpfs) + 1,5 GB (kernel memory) = 3 GB
Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
Reviewed-by: Dave Young <dyoung at redhat.com>
Signed-off-by: Simon Horman <horms at verge.net.au>
>
> I think there is a practical limit at about 50% of memory (because we
> need two copies in memory the source and the destination pages), but
> anything else is pretty much reasonable and should have a fair chance of
> working.
>
> A limit that reflected that reality above would be interesting.
> Anything else will likely cause someone trouble in the futrue.
Maybe one should test his ramdisk first to ensure it works first before
really using it.
Thanks
Dave
More information about the kexec
mailing list