From: Phil Blundell <philb@gnu.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH 2/6] conf/bitbake: improve compression image handling
Date: Fri, 08 Apr 2011 13:18:00 +0100 [thread overview]
Message-ID: <1302265080.14449.513.camel@phil-desktop> (raw)
In-Reply-To: <4D9E4D66.1000701@mentor.com>
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@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.
next prev parent reply other threads:[~2011-04-08 12:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-07 13:19 [PATCH 0/6] Patchset for pushing into master Otavio Salvador
2011-04-07 13:19 ` [PATCH 1/6] udev (165): move ConsoleKit support to udev-consolekit package Otavio Salvador
2011-04-07 13:19 ` [PATCH 2/6] conf/bitbake: improve compression image handling Otavio Salvador
2011-04-07 13:19 ` [PATCH 3/6] xorg-xserver-common.inc: drop .la files from packages Otavio Salvador
2011-04-07 13:19 ` [PATCH 4/6] xserver-xorg (1.9.4): enable xephyr Otavio Salvador
2011-04-07 13:19 ` [PATCH 5/6] xserver-xorg (git): " Otavio Salvador
2011-04-07 13:19 ` [PATCH 6/6] freerdp: update version to 2009-03-29 snapshot Otavio Salvador
2011-04-07 17:27 ` Phil Blundell
2011-04-07 17:34 ` Otavio Salvador
2011-04-11 13:10 ` [PATCH 4/6] xserver-xorg (1.9.4): enable xephyr Martin Jansa
2011-04-11 13:32 ` Otavio Salvador
2011-04-11 21:45 ` Khem Raj
2011-04-07 17:23 ` [PATCH 2/6] conf/bitbake: improve compression image handling Phil Blundell
2011-04-07 17:29 ` Otavio Salvador
2011-04-07 23:48 ` Tom Rini
2011-04-08 11:50 ` Otavio Salvador
2011-04-08 12:18 ` Phil Blundell [this message]
2011-04-08 12:38 ` Otavio Salvador
2011-04-08 4:32 ` Martin Jansa
2011-04-08 11:51 ` Otavio Salvador
2011-04-07 17:21 ` [PATCH 1/6] udev (165): move ConsoleKit support to udev-consolekit package Phil Blundell
2011-04-07 17:30 ` Otavio Salvador
-- strict thread matches above, loose matches on Subject: below --
2011-04-01 12:16 Otavio Salvador
2011-04-01 12:16 ` [PATCH 2/6] conf/bitbake: improve compression image handling Otavio Salvador
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1302265080.14449.513.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.