[OE-core] [PATCH 0/3] Fix xz compression command and optimize compression time

[Andrei Gherzan]

On Fri, Jul 13, 2012 at 11:19 AM, Andrea Adami <andrea.adami at gmail.com>wrote:

> On Fri, Jul 13, 2012 at 8:45 AM, Koen Kooi <koen at dominion.thruhere.net>
> wrote:
> >
> > Op 12 jul. 2012, om 21:22 heeft Saul Wold het volgende geschreven:
> >
> >> On 07/12/2012 11:58 AM, Koen Kooi wrote:
> >>> Any volunteers to test this on a system with >4 real cores?
> >>>
> >>
> >> Koen,
> >>
> >> Does OE-Core or Poky have an image setup for using .xz by default?
> >
> > No, and as you can see from Andrei's patches, it would have never worked
> :)
> >
> > regards,
> >
> > Koen
> >
>
> This leads to a similar remark for lzma:
>
> The xz/lzma have been added with commit  38334ac and at that time both
> where using XZ_COMPRESSION_LEVEL.
>
> The code has been refactored afterwards and what happened is that lzma
> now defaults to compression 7 (the default) while xz is way too high
> (default is 6).
>
>
Nope. It's default value is -9.


> There is a well hidden pitfall with that, being that any image,
> including the initramfs, will use that compression factor.
>
> As you can notice in that (old) man xz [2]  the memory requirements
>

What old version?


> are very high and what did happen to me was that the cpio.lzma could
> not be decompressed thus kernel could not boot (we override now the
> value setting "-e2" in our BSP).
>
>
Without threads, memory demand was around 700mb. So it should be ok for
most of machines.

Adding more threads will multiply that figures.
>
>
Indeed. With 8GB memory at my disposal i couldn't compress an image with -e
-9 and -T 0 (-T 4)/

@g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120713/8d7be8d7/attachment-0002.html>