Small and unimportant description mistakes of Kernel compression mode in kernel config

Small and unimportant description mistakes of Kernel compression mode in kernel config

[qasdfgtyuiop]

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 :)

Re: Small and unimportant description mistakes of Kernel compression mode in kernel config

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Am 27.03.2012 12:19, schrieb qasdfgtyuiop:
> 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.
[...]
> 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

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

[PATCH] kconfig: update compression algorithm info

[Randy Dunlap]

From: Randy Dunlap <rdunlap@xenotime.net>

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.

Reported-by: qasdfgtyuiop@gmail.com
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 init/Kconfig |   11 +++++------
 usr/Kconfig  |   10 +++++-----
 2 files changed, 10 insertions(+), 11 deletions(-)

--- lnx-34-rc3.orig/usr/Kconfig
+++ lnx-34-rc3/usr/Kconfig
@@ -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.
 
--- lnx-34-rc3.orig/init/Kconfig
+++ lnx-34-rc3/init/Kconfig
@@ -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

[Lasse Collin]

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).

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Re: [PATCH] kconfig: update compression algorithm info

[H. Peter Anvin]

On 04/18/2012 09:40 AM, Lasse Collin wrote:
>   - 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

[Lasse Collin]

On 2012-04-18 H. Peter Anvin wrote:
> On 04/18/2012 09:40 AM, Lasse Collin wrote:
> >   - 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.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Re: [PATCH] kconfig: update compression algorithm info

[Markus Trippelsdorf]

On 2012.04.18 at 20:09 +0300, Lasse Collin wrote:
> On 2012-04-18 H. Peter Anvin wrote:
> > On 04/18/2012 09:40 AM, Lasse Collin wrote:
> > >   - 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.

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

-- 
Markus

Re: [PATCH] kconfig: update compression algorithm info

[H. Peter Anvin]

On 04/18/2012 10:23 AM, Markus Trippelsdorf wrote:
> 
> 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

[Markus Trippelsdorf]

On 2012.04.18 at 10:29 -0700, H. Peter Anvin wrote:
> On 04/18/2012 10:23 AM, Markus Trippelsdorf wrote:
> > 
> > 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.

> 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...

-- 
Markus

Re: [PATCH] kconfig: update compression algorithm info

[H. Peter Anvin]

On 04/18/2012 10:09 AM, Lasse Collin wrote:
> 
> 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