From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935040AbcI0TcK (ORCPT ); Tue, 27 Sep 2016 15:32:10 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:33051 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934281AbcI0TcB (ORCPT ); Tue, 27 Sep 2016 15:32:01 -0400 Subject: [PATCH v2 2/2] initramfs: allow again choice of the embedded compression algorithm To: linux-kernel@vger.kernel.org References: <54239E69.4050803@klondike.es> <57EAC8CC.3070602@klondike.es> Cc: P J P , Paul Bolle , Andrew Morton From: klondike Message-ID: <57EAC91B.4040407@klondike.es> Date: Tue, 27 Sep 2016 21:31:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <57EAC8CC.3070602@klondike.es> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sLw388rO39rGAuA7WA1QQla8CETF5aEhQ" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sLw388rO39rGAuA7WA1QQla8CETF5aEhQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Choosing the appropriate compression option when using an embeded initram= fs can result in significant size differences in the resulting data. This is caused by avoiding double compression of the initramfs contents. For example on my tests, choosing CONFIG_INITRAMFS_COMPRESSION_NONE when compressing the kernel using XZ) results in up to 500KiB differences (9MiB to 8.5MiB) in the kernel size as the dictionary will not get polluted with uncomprensible data and may reuse kernel data too. Despite embedding an uncompressed initramfs, a user may want to allow for= a compressed extra initramfs to be passed using the rd system, for example = to boot a recovery system. Commit 9ba4bcb645898d562498ea66a0df958ef0e7a68c ("initramfs: read CONFIG_RD_ variables for initramfs compression") broke that behavior by making the choice based on CONFIG_RD_* instead of adding= CONFIG_INITRAMFS_COMPRESSION_LZ4. Saddly, CONFIG_RD_* is also used to choose the supported RD compression algorithms by the kernel and a user m= ay want to suppport more than one. This patch also reverses 3e4e0f0a8756dade3023d1f47d50fbced7749788 ("initramfs: remove "compression mode" choice") restoring back the "compression mode" choice and includes the CONFIG_INITRAMFS_COMPRESSION_L= Z4 option which was never added. As a result the following options are added or readed affecting the embed= ded initramfs compression: INITRAMFS_COMPRESSION_NONE Do no compression INITRAMFS_COMPRESSION_GZIP Compress using gzip INITRAMFS_COMPRESSION_BZIP2 Compress using bzip2 INITRAMFS_COMPRESSION_LZMA Compress using lzma INITRAMFS_COMPRESSION_XZ Compress using xz INITRAMFS_COMPRESSION_LZO Compress using lzo INITRAMFS_COMPRESSION_LZ4 Compress using lz4 These depend on the corresponding CONFIG_RD_* option being set (except NO= NE which has no dependencies). This patch depends on the previous one (the previous version didn't) to simplify the way in which the algorithm is chosen and keep backwards compatibility with the behaviour introduced by commit 9ba4bcb645898d562498ea66a0df958ef0e7a68c Signed-off-by: Francisco Blas Izquierdo Riera (klondike) Cc: P J P Cc: Paul Bolle Cc: Andrew Morton diff --git a/usr/Kconfig b/usr/Kconfig index bf8e8f1..6278f13 100644 --- a/usr/Kconfig +++ b/usr/Kconfig @@ -99,8 +99,125 @@ config RD_LZ4 Support loading of a LZ4 encoded initial ramdisk or cpio buffer If unsure, say N. =20 +choice + prompt "Built-in initramfs compression mode" + depends on INITRAMFS_SOURCE!=3D"" + optional + help + This option allows you to decide by which algorithm the builtin + initramfs will be compressed. Several compression algorithms are + available, which differ in efficiency, compression and + decompression speed. Compression speed is only relevant + when building a kernel. Decompression speed is relevant at + each boot. Also the memory usage during decompression may become + relevant on memory constrained systems. This is usually based on t= he + dictionary size of the algorithm with algorithms like XZ and LZMA + featuring large dictionary sizes. + + High compression options are mostly useful for users who are + low on RAM, since it reduces the memory consumption during + boot. + + Keep in mind that your build system needs to provide the appropria= te + compression tool to compress the generated initram cpio file for + embedding. + + If in doubt, select 'None' + +config INITRAMFS_COMPRESSION_NONE + bool "None" + help + Do not compress the built-in initramfs at all. This may sound wasteful + in space, but, you should be aware that the built-in initramfs will be + compressed at a later stage anyways along with the rest of the kernel, + on those architectures that support this. However, not compressing the + initramfs may lead to slightly higher memory consumption during a + short time at boot, while both the cpio image and the unpacked + filesystem image will be present in memory simultaneously + +config INITRAMFS_COMPRESSION_GZIP + bool "Gzip" + depends on RD_GZIP + help + Use the old and well tested gzip compression algorithm. Gzip provi= des + a good balance between compression ratio and decompression speed a= nd + has a reasonable compression speed. It is also more likely to be + supported by your build system as the gzip tool is present by defa= ult + on most distros. + +config INITRAMFS_COMPRESSION_BZIP2 + bool "Bzip2" + depends on RD_BZIP2 + help + It's compression ratio and speed is intermediate. Decompression sp= eed + is slowest among the choices. The initramfs size is about 10% smal= ler + with bzip2, in comparison to gzip. Bzip2 uses a large amount of + memory. For modern kernels you will need at least 8MB RAM or more = for + booting. + + If you choose this, keep in mind that you need to have the bzip2 t= ool + available to be able to compress the initram. + +config INITRAMFS_COMPRESSION_LZMA + bool "LZMA" + depends on RD_LZMA + help + This algorithm's compression ratio is best but has a large diction= ary + size which might cause issues in memory constrained systems. + Decompression speed is between the other choices. Compression is + slowest. The initramfs size is about 33% smaller with LZMA in + comparison to gzip. + + If you choose this, keep in mind that you may need to install the = xz + or lzma tools to be able to compress the initram. + +config INITRAMFS_COMPRESSION_XZ + bool "XZ" + depends on RD_XZ + help + XZ uses the LZMA2 algorithm and has a large dictionary which may cause + problems on memory constrained systems. The initramfs size is abou= t + 30% smaller with XZ in comparison to gzip. Decompression speed is + better than that of bzip2 but worse than gzip and LZO. Compression= is + slow. + + If you choose this, keep in mind that you may need to install the = xz + tool to be able to compress the initram. + +config INITRAMFS_COMPRESSION_LZO + bool "LZO" + depends on RD_LZO + help + It's compression ratio is the second poorest amongst the choices. = The + kernel size is about 10% bigger than gzip. Despite that, it's + decompression speed is the second fastest and it's compression spe= ed + is quite fast too. + + If you choose this, keep in mind that you may need to install the lzop + tool to be able to compress the initram. + +config INITRAMFS_COMPRESSION_LZ4 + bool "LZ4" + depends on RD_LZ4 + help + It's compression ratio is the poorest amongst the choices. The ker= nel + size is about 15% bigger than gzip; however its decompression spee= d + is the fastest. + + If you choose this, keep in mind that most distros don't provide l= z4 + by default which could cause a build failure. + +endchoice + config INITRAMFS_COMPRESSION string + default "" if INITRAMFS_COMPRESSION_NONE + default ".gz" if INITRAMFS_COMPRESSION_GZIP + default ".bz2" if INITRAMFS_COMPRESSION_BZIP2 + default ".lzma" if INITRAMFS_COMPRESSION_LZMA + default ".xz" if INITRAMFS_COMPRESSION_XZ + default ".lzo" if INITRAMFS_COMPRESSION_LZO + default ".lz4" if INITRAMFS_COMPRESSION_LZ4 default ".gz" if RD_GZIP default ".lz4" if RD_LZ4 default ".lzo" if RD_LZO --sLw388rO39rGAuA7WA1QQla8CETF5aEhQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJX6skbAAoJEPLcgKVuD9jNfPMP/2QxBzlfNrLFYvH1j+WRjL1Q kPDdao8iROQkTcdEtatmg8B1ICZWgbcRmtz/PvFHJMkL1Wxz+OQrhCv/W6tCumSQ wGNpXcGWkQAqsmDPPu7zUJyY4Sg+sVYz+CiNTqK84CIUYAkJS8ib3h0AxrYomTC+ 4D9s6K0wEmketMCOKA2CPgkPcJjckFDxTNHEaFp9hAaItl98AO3+F1Q9LC6VgMQ7 pmX02P5q6KYyGTECZ/ctOmXwheQ647gJY+RzrkHBjQxyYUCQy8BJF0aJyWBMAth5 0ckKW/+EuqYjtJBaGHtPmAoEge7g9vml04VXvW3XHzULOMU1oRpQeioks0L/OPce ei749Vy6eXT9+qVjVIVGia/Gj8jz1mMg30XwSx/kAl3JvH77LUNiq0641MX3w+Jz aIjy4UNIOr9gcnypZfJKpKZ/EYZGA8ZTUb6CKYfayp2qAj6IaielSHakJerbIDJU TX1oL6RCDhGDs0ACeBCzFqsARpCN542E0vNeW3RP59GgkwvmQbJPi3AiyC/NAiIn 5P6ftjRl40tPR3ftun2kq6fCl+2xWQJ6+O7WhhXhHE4SY6SyjEDwNP6DdwKzi1Vz WcKYCRm6Ob+iItAYIPR4N5k8fWkpJFlRnDqoa35wfJOUK8dAbgPHE6G8OUoATecn yUTVi7QetY0sKPa0R3b+ =j2EQ -----END PGP SIGNATURE----- --sLw388rO39rGAuA7WA1QQla8CETF5aEhQ--