[oe] [PATCH 2/6] conf/bitbake: improve compression image handling

Phil Blundell philb at gnu.org
Fri Apr 8 12:18:00 UTC 2011


On Thu, 2011-04-07 at 16:48 -0700, Tom Rini wrote:
> On 04/07/2011 10:29 AM, Otavio Salvador wrote:
> > On Thu, Apr 7, 2011 at 14:23, Phil Blundell <philb at gnu.org> wrote:
> >> On Thu, 2011-04-07 at 13:19 +0000, Otavio Salvador wrote:
> >>>  XZ_COMPRESSION_LEVEL ?= "-e -9"
> >>>  LZMA_COMPRESSION_LEVEL ?= "-e -9"
> >>> +GZIP_COMPRESSION_LEVEL ?= "-9"
> >>> +BZIP2_COMPRESSION_LEVEL ?= "-9"
> >>
> >> It seems a bit sad to have to keep adding new vars to the global
> >> configuration set (and hence parse them for every single recipe) every
> >> time someone wants to tweak a new compression format.  Can we not just
> >> have a single IMAGE_COMPRESSION_LEVEL that does for everything?
> > 
> > For me it doesn't matter; I can add it if preferred.
> 
> Why are we even tweaking gzip/bzip2?  XZ/LZMA can have serious tradeoffs
> at higher levels but I thought for bzip2/gzip it was either do it or no
> compression, not "turn it down a little bit".

There is a bit of a tradeoff for gzip, though I'm not sure you would
notice it on modern hardware.  For bzip2 it's more significant; if
you're bzipping large files (several GB) then the choice between -9 and
-1 is quite noticeable even on a relatively powerful cpu.  I'm not sure
you'd notice much difference with either gzip or bzip on a 32MB jffs2
image.

And for unzipping, my recollection is that the decompressor stages of
both gzip and bzip run in more-or-less constant time irrespective of the
settings that you used when compressing.  

So yeah, I agree, it isn't obvious that there is going to be much
real-world benefit from tweaking these knobs for gzip and bzip2.  If
someone wants that ability then fine, but ideally in a way that doesn't
cause further metadata bloat for everyone else.  One obvious way to do
that would be to put the default variable settings in the
image-generating classes, rather than in bitbake.conf, so that they
don't get set at all for the majority of recipes if you are happy to
accept the defaults.

p.






More information about the Openembedded-devel mailing list