Re: [RFC] split floppy support off biosdisk

["Javier Martín" <lordhabbit@gmail.com>]

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

El mié, 18-06-2008 a las 01:35 +0800, Bean escribió:
> On Wed, Jun 18, 2008 at 1:23 AM, Javier Martín <lordhabbit@gmail.com>
> wrote:
> > I'm currently checking the memory requisites of LZMA decompression
> > depending on the -1..9 compression setting, and will report back when
> > finished
> 
> Hi,
> 
> Well, actually current lzo decompresser uses similar method,
> decompress the data directly to 0x100000. The compressed kernel is
> only used in i386-pc platform, and space at 0x100000 should be
> available, as Linux kernel will be loaded at this address as well.
> 
> About lzma setting, although I can't be sure, but the default seems to
> gain the best result.
> 

jmp 1f

Here are the results of my "investigation": in large files (the kernel
tarball) LZMA is the absolute king, with some 3% gains over bzip2 at the
same -n compression level and more than 7% over gzip. However, memory
used by lzma for decompression increases with each -n compression level
from 2MB while reading a "-1" .lzma file to 34MB reading a "-9" file.
Memory usage for bzip2 also fluctuates, though less dramatically: from
1MB in -1 to 4 in -9. Mem usage of gzip is constant at 500KB.

1:

That was the theory: now for the actual use in _small_ files like
core.img. I found that bzip2 is a no-go, since it gives worse results
than gzip in this kind of files and is also more complex. LZMA shows
better results than gzip, but is the additional complexity worth the
savings? One would have to code both decompressors and check, but I
think the best option is switch to gzip, mainly because LZO compression
does _not_ save nearly anything!

ORIGINAL FILE: /boot/grub/core.img (28449 bytes in Ubuntu Hardy default)

CLvl     LZO-sav%    GZIP-sav%    LZMA-sav%
   1   28215-0.82   26647-6.33   26270-7.66
   2   28211-0.84   26643-6.35   26270-7.66
   3  *28211-0.84   26644-6.35   26185-7.96
   4   28211-0.84   26600-6.50   26185-7.96
   5   28211-0.84   26601-6.50   26185-7.96
   6   28211-0.84  *26596-6.52   26185-7.96
   7   28129-1.13   26596-6.52  *26185-7.96
   8   28129-1.13   26596-6.52   26185-7.96
   9   28129-1.13   26596-6.52   26185-7.96

* indicates the default compression level
Apps used: lzop v.1.01, GNU gzip 1.3.12, LZMA 4.43

With these results, I believe that the first conclusion is immediate: we
should dump LZO because even in its "best" compression level it saves
just 320 bytes, or 1.13%. Of the alternatives, while LZMA provides a
superior compression level, I think Gzip offers the best compromise
between code complexity and space savings. Besides, it is already used
in the Linux kernel for this very purpose, so we might even find that we
"just" need to copy, paste and adjust a bit.

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]