> Choosing a compression level is (still) not supported, but choosing any
> combination of gzip/bzip2 is already implemented. I wonder if it is useful
> to have compression-level-numbers? The patch uses '-9' compression in any
> case (gzip/bzip2 kernel/ramdisk).
It is definitely useful to be able to control the compression
number, as it has drastic effects on decompression memory
requirements. Especially between, say, -6 and -9, there is a
lot of memory usage increase without a lotta more compression,
controlling this may let your kernel decompress on a 4MB machine
it might not otherwise work on. Consider:
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642
Leaving it at -s only is probably OK, also, you would need major rework
of the patch to support the fast option, as I removed all that code
completely, it has alternate routines for much of bzip2, but supporting
control of the compression level will be really easy, since it only
affects the actual bzip2ing in the Makefile.
-Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/