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
