Re: [RFC] split floppy support off biosdisk

[Bean]

On Wed, Jun 18, 2008 at 7:40 PM, Javier Martín <address@hidden> wrote:
> El mar, 17-06-2008 a las 23:49 -0400, Pavel Roskin escribió:
>> On Wed, 2008-06-18 at 05:14 +0200, Javier Martín wrote:
>>
>> > ORIGINAL FILE: /boot/grub/core.img (28449 bytes in Ubuntu Hardy default)
>>
>> That's an already compressed file!  Please see my posts in the thread.
>> We should be testing compression on the data we are actually
>> compressing.
> Yeah, I noticed it _after_ posting and sent another message to the
> effect. I repeated the tests, now with an uncompressed image. For the
> "scientific method" guys wanting to repeat or extend the test, this is
> how the it was performed:
>
> /boot/grub$ cat kernel.img pc.mod fshelp.mod ext2.mod > ~/core.img
> /boot/grub$ cd
> ~$ stat -c %s core.img
> 40412   # Size of the uncompressed file (for later)
> ~$ for n in {1..9}; do
>        lzop core.img -c -$n > ./core.$n.lzo
>        gzip core.img -c -$n > ./core.$n.gz
>        bzip2 core.img -c -k -$n > ./core.$n.bz2
>        lzma core.img -c -k -$n > ./core.$n.lzma
> done
> ~$ for comp in lzo gz bz2 lzma; do
>        echo $comp
>        for n in {1..9}; do
>                echo $(stat -c %s ./core.$n.$comp)-$(dc -e "2 k 100 $(stat -c %
> s ./core.$n.$comp) 404.12 / - p")
>        done
> done
>
> For me, the results are:
>
> CL     LZO-%sav    GZIP-%sav   BZIP2-%sav    LZMA-%sav
>  1   29391-27.3   24171-40.2   22979-43.2   21569-46.7
>  2   29279-27.6   23913-40.9        x       21567-46.7
>  3  *     x       23785-41.2        x       20922-48.3
>  4        x       23350-42.3        x            x
>  5        x       23148-42.8        x       20924-48.3
>  6        x      *23074-43.0        x            x
>  7   25250-37.6   23071-43.0        x      *     x
>  8   25163-37.8   23045-43.0        x       20929-48.3
>  9   25162-37.8   23035-43.0  *     x            x
> Where:
> * indicates the default compression level
> x indicates "same as above"
> The original file size was 40412 bytes
>
> I hope the results are a bit more useful this time. The "uncompressed
> chunk" of nearly 1KiB was not taken into account, i.e. the whole file
> was compressed by every algorithm. My conclusions are:
> * LZO is pretty bad unless we set the maximum compression level, which
> is not a problem because required memory and CPU is still nearly zero.
> Seemingly, grub-mkimage already compresses with high CLs because the
> core.img it generated with the same parameters than my cat'ed test image
> was 25928 bytes long, with the uncompressed part and the decompressor.
> * GZip is okay in its default compression level of -6, but, as LZO, we
> don't lose nearly anything in terms of CPU and memory by pushing it to
> -9. The particular advantage of this algorithm is that is already
> implemented for this same purpose in the Linux kernel, so may be we
> could use copy-paste to some point and relieve us some work. We'd save
> up to 2 KiB in my test image, assuming similar decompressor size.
> * BZip2 is also fine - its results are immutable throughout the CLs, I
> suppose because the whole file fits in its -1 compression dictionary of
> 100 KiB. I don't think we'd benefit a lot from this particular algorithm
> with files this small, and thus I prefer GZip over it.
> * LZMA is the king of compression, and so we gain more bytes for code,
> but at the cost of an implementation of unknown size - the C version of
> the decompressor in the coreboot project seemed to be a bit big, but
> maybe our local assembly gurus could tune it down. We'd save up to 4 KiB
> in my test image, assuming similar decompressor size.
>
> I hope I did not make any embarrassing mistakes this time :-)

Hi,

We also need to consider how close it's to the upper limit, 32256,
which is the available free space in the mbr. To access partition with
lvm and raid enabled, we need to use:

biosdisk pc ext2 fshelp lvm raid

If you rerun the test using the above modules, you will notice that
besides lzma, others are close to the upper limit.

-- 
Bean