[lkml]   [2020]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [PATCH] initramfs: don't double-compress built-in initramfs if the kernel is compressed
On Tue, Feb 04, 2020 at 11:22:19AM +0900, Masahiro Yamada wrote:
> Hi.
> On Tue, Feb 4, 2020 at 6:16 AM Arvind Sankar <> wrote:
> >
> > If the kernel is going to be compressed anyway, there is no point in
> > double-compressing the built-in initramfs. Hide the built-in initramfs
> > compression choice in this case.
> >
> > Signed-off-by: Arvind Sankar <>
> Double-compression slightly reduces the data size.
> And, keeping the bare vmlinux small is beneficial, IMHO.

Ok. In my setup (kernel is compressed by xz), none for the builtin
initramfs is optimal by a measurable amount, but I that will depend on
config/initramfs contents/compression methods, so might well not be true
in general. Maybe add a note to the help text?

none 7030816 arch/x86/boot/bzImage
gz 7382144 arch/x86/boot/bzImage
bz2 7353696 arch/x86/boot/bzImage
lzma 7118176 arch/x86/boot/bzImage
xz 7126400 arch/x86/boot/bzImage
lzo 7379360 arch/x86/boot/bzImage
lz4 7335712 arch/x86/boot/bzImage

diff --git a/usr/Kconfig b/usr/Kconfig
index a6b68503d177..b68910b225fc 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -125,6 +125,12 @@ choice
low on RAM, since it reduces the memory consumption during

+ Note that if the kernel itself is compressed, the builtin initramfs
+ will be compressed twice, first by the algorithm selected here, and
+ then by the kernel compression method chosen. This may increase the
+ final image size, so you should test whether compressing the builtin
+ initramfs provides any savings.
Keep in mind that your build system needs to provide the appropriate
compression tool to compress the generated initram cpio file for
 \ /
  Last update: 2020-02-04 17:30    [W:0.101 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site