Small and unimportant description mistakes of Kernel compression mode in kernel config
the mistake is enclosed by brackets[]
In bzip2 the description is:
Its compression ratio and speed is intermediate. Decompression speed is slowest among the [three]. The kernel size is about 10% smaller 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.
In lzma the description is:
The most recent compression algorithm.
Its ratio is best, decompression speed is [between the other two]. Compression is slowest. The kernel size is about 33% smaller with LZMA in comparison to gzip.
The LZO's description is:
Its compression ratio is the poorest among the [4]. The kernel size is about 10% bigger than gzip; however its speed (both compression and decompression) is the fastest.
But there are five compression algorithms in total :)
Am 27.03.2012 12:19, schrieb qasdfgtyuiop:
Quoted 3 lines
Its ratio is best, decompression speed is [between the other two]. Compression is slowest. The kernel size is about 33% smaller with LZMA in comparison to gzip.
[...]
Quoted 5 lines
Its compression ratio is the poorest among the [4]. The kernel size is about 10% bigger than gzip; however its speed (both compression and decompression) is the fastest.
But there are five compression algorithms in total :)
AND nice red uniforms!
SCNR,
Tilman
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
PATCH 1/1 kconfig: update compression algorithm info
In reply to qasdfgtyuiopFrom: Randy Dunlap <[email protected]>
There have been new compression algorithms added without updating nearby relevant descriptive text that refers to
(a) the number of compression algorithms and (b) the most recent one. Fix these inconsistencies.
--- init/Kconfig | 11 +++++------ usr/Kconfig | 10 +++++----- 2 files changed, 10 insertions(+), 11 deletions(-)
usr/Kconfig +5 -5
@@ -134,7 +134,7 @@ config INITRAMFS_COMPRESSION_BZIP2 depends on RD_BZIP2 help Its compression ratio and speed is intermediate. - Decompression speed is slowest among the four. The initramfs + Decompression speed is slowest among the choices. The initramfs size is about 10% smaller 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.
@@ -143,9 +143,9 @@ config INITRAMFS_COMPRESSION_LZMA bool "LZMA" depends on RD_LZMA help - The most recent compression algorithm. - Its ratio is best, decompression speed is between the other - three. Compression is slowest. The initramfs size is about 33% + This algorithm's compression ratio is best. + Decompression speed is between the other choices. + Compression is slowest. The initramfs size is about 33% smaller with LZMA in comparison to gzip. config INITRAMFS_COMPRESSION_XZ
@@ -161,7 +161,7 @@ config INITRAMFS_COMPRESSION_LZO bool "LZO" depends on RD_LZO help - Its compression ratio is the poorest among the four. The kernel + Its compression ratio is the poorest among the choices. The kernel size is about 10% bigger than gzip; however its speed (both compression and decompression) is the fastest.
init/Kconfig +5 -6
@@ -164,7 +164,7 @@ config KERNEL_BZIP2 depends on HAVE_KERNEL_BZIP2 help Its compression ratio and speed is intermediate. - Decompression speed is slowest among the three. The kernel + Decompression speed is slowest among the choices. The kernel size is about 10% smaller 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.
@@ -173,10 +173,9 @@ config KERNEL_LZMA bool "LZMA" depends on HAVE_KERNEL_LZMA help - The most recent compression algorithm. - Its ratio is best, decompression speed is between the other - two. Compression is slowest. The kernel size is about 33% - smaller with LZMA in comparison to gzip. + This compression algorithm's ratio is best. Decompression speed + is between gzip and bzip2. Compression is slowest. + The kernel size is about 33% smaller with LZMA in comparison to gzip. config KERNEL_XZ bool "XZ"
@@ -197,7 +196,7 @@ config KERNEL_LZO bool "LZO" depends on HAVE_KERNEL_LZO help - Its compression ratio is the poorest among the 4. The kernel + Its compression ratio is the poorest among the choices. The kernel size is about 10% bigger than gzip; however its speed (both compression and decompression) is the fastest.
Re: [PATCH] kconfig: update compression algorithm info
Quoted 4 lines · On 2012-04-17 Randy Dunlap wrote:
There have been new compression algorithms added without updating nearby relevant descriptive text that refers to
(a) the number of compression algorithms and (b) the most recent one. Fix these inconsistencies.
It could also be good to fix which algo has the best compression ratio. XZ supports BCJ filters on some archs and on those it will give a few percent smaller kernel than LZMA. Without BCJ, XZ and LZMA are practically tied.
If you feel like it, maybe it would be nice to have some recommendations in the descriptions:
- gzip is a safe choice if unsure what to do.
- XZ is good when small size is important (embedded systems, live CDs).
- LZO should give the fastest boot from a hard disk (desktop systems where file size doesn't matter much).
Signature · 1 line
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
Re: [PATCH] kconfig: update compression algorithm info
Quoted 2 lines · Lasse Collin
- LZO should give the fastest boot from a hard disk (desktop systems where file size doesn't matter much).
That really depends on the speed of your disk vs CPU.
-hpa
Re: [PATCH] kconfig: update compression algorithm info
Quoted 5 lines · On 2012-04-18 H. Peter Anvin wrote:
Quoted 2 lines · Lasse Collin
- LZO should give the fastest boot from a hard disk (desktop systems where file size doesn't matter much).
That really depends on the speed of your disk vs CPU.
Yes. Maybe it isn't good to give so clear recommendation for LZO over gzip here.
I think it is still safe to say that gzip and LZO are better than bzip2, XZ, or LZMA for compressing a kernel that will be loaded from a normal hard disk. It would be unusual if reading the disk was so slow that e.g. XZ would make the booting faster than gzip.
Signature · 1 line
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
Re: [PATCH] kconfig: update compression algorithm info
Quoted 7 lines · Lasse Collin
Quoted 5 lines · On 2012-04-18 H. Peter Anvin wrote:
Quoted 2 lines · Lasse Collin
- LZO should give the fastest boot from a hard disk (desktop systems where file size doesn't matter much).
That really depends on the speed of your disk vs CPU.
Quoted 7 lines
Yes. Maybe it isn't good to give so clear recommendation for LZO over gzip here.
I think it is still safe to say that gzip and LZO are better than bzip2, XZ, or LZMA for compressing a kernel that will be loaded from a normal hard disk. It would be unusual if reading the disk was so slow that e.g. XZ would make the booting faster than gzip.
When btrfs will finally implement LZ4 compression this would be the obvious candidate for the fastest boot algo, because its decompression speed is amazing.
For example here is a comparison with LZO on boot/compressed/vmlinux.bin:
memcpy = 75 ms (10251 MB/s), 13436968->13436968
Codec version args Size (Ratio) C.Speed D.Speed LZ4 r59 12 4952064 (x 2.71) C: 518 MB/s D:1472 MB/s LZO 2.05 1x1 4825088 (x 2.78) C: 472 MB/s D: 504 MB/s
Signature · 1 line
Markus
Re: [PATCH] kconfig: update compression algorithm info
Quoted 5 lines · Markus Trippelsdorf
When btrfs will finally implement LZ4 compression this would be the obvious candidate for the fastest boot algo, because its decompression speed is amazing.
Uh, no (and what does btrfs have to do with anything here?)
The issue is that the ratio of I/O speed to CPU can mean that a slower decompression algorithm with better compression can still win, time-wise, if your media is slow and your CPU is fast.
-hpa
Re: [PATCH] kconfig: update compression algorithm info
Quoted 8 lines · H. Peter Anvin
Quoted 5 lines · Markus Trippelsdorf
When btrfs will finally implement LZ4 compression this would be the obvious candidate for the fastest boot algo, because its decompression speed is amazing.
Uh, no (and what does btrfs have to do with anything here?)
I was referring to a possible library implementation.
Quoted 3 lines
The issue is that the ratio of I/O speed to CPU can mean that a slower decompression algorithm with better compression can still win, time-wise, if your media is slow and your CPU is fast.
Sure. Only measurements will tell...
Signature · 1 line
Markus
Re: [PATCH] kconfig: update compression algorithm info
In reply to Lasse CollinQuoted 6 lines · Lasse Collin
I think it is still safe to say that gzip and LZO are better than bzip2, XZ, or LZMA for compressing a kernel that will be loaded from a normal hard disk. It would be unusual if reading the disk was so slow that e.g. XZ would make the booting faster than gzip.
Not really, because the boot loader is dependent on the firmware, which can sometimes be infernally stupid.
-hpa