Skip to contentSkip to conversation

Fix xz compression command and optimize compression time

PATCH Applied Andrei Gherzan 6 participants 15 messages Jul 12, 2012 – Jul 17, 2012

lore
Share & tools
lore
#0 lore raw

cover Fix xz compression command and optimize compression time

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

 meta/classes/image_types.bbclass |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH 1/3 image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed data to file

Having -c modifier makes xz to output the compressed data to stdout. In this way the needed data will be in the do_rootfs log.
Redirect data to ${IMAGE_NAME}.rootfs.${type}.xz .

---
 meta/classes/image_types.bbclass |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/image_types.bbclass +1 -1
index 5734edf..0e79820 100644
@@ -236,7 +236,7 @@ COMPRESSIONTYPES = "gz bz2 lzma xz"
 COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}"
 COMPRESS_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}.rootfs.${type} > ${IMAGE_NAME}.rootfs.${type}.gz"
 COMPRESS_CMD_bz2 = "bzip2 -f -k ${IMAGE_NAME}.rootfs.${type}"
-COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type}"
+COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > ${IMAGE_NAME}.rootfs.${type}.xz"
 COMPRESS_DEPENDS_lzma = "xz-native"
 COMPRESS_DEPENDS_gz = ""
 COMPRESS_DEPENDS_bz2 = ""
Signature · 1 line
1.7.9.5
#2 lore raw

PATCH 2/3 image_types.bbclass: Add XZ variable to set number of threads to be used while compressing

Default this variable to 0. This will make xz use as many threads as there are CPU cores on the system.

---
 meta/classes/image_types.bbclass |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
meta/classes/image_types.bbclass +2 -1
index 0e79820..b19ad3b 100644
@@ -124,6 +124,7 @@ def imagetypes_getdepends(d):
 
 XZ_COMPRESSION_LEVEL ?= "-e -9"
 XZ_INTEGRITY_CHECK ?= "crc32"
+XZ_THREADS ?= "-T 0"
 
 IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 -n ${EXTRA_IMAGECMD}"
 IMAGE_CMD_sum.jffs2 = "${IMAGE_CMD_jffs2} && sumtool -i ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \
@@ -236,7 +237,7 @@ COMPRESSIONTYPES = "gz bz2 lzma xz"
 COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}"
 COMPRESS_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}.rootfs.${type} > ${IMAGE_NAME}.rootfs.${type}.gz"
 COMPRESS_CMD_bz2 = "bzip2 -f -k ${IMAGE_NAME}.rootfs.${type}"
-COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > ${IMAGE_NAME}.rootfs.${type}.xz"
+COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type} > ${IMAGE_NAME}.rootfs.${type}.xz"
 COMPRESS_DEPENDS_lzma = "xz-native"
 COMPRESS_DEPENDS_gz = ""
 COMPRESS_DEPENDS_bz2 = ""
Signature · 1 line
1.7.9.5
#3 lore raw

PATCH 3/3 image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

In reply to Andrei Gherzan

Having XZ_COMPRESSION_LEVEL on -e -9 and -T 0 will make xz eat more than 6Gb memory. Reduce this to -6 to make xz to use about 471Mb on the tested machine.

---
 meta/classes/image_types.bbclass |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/image_types.bbclass +1 -1
index b19ad3b..727d8d6 100644
@@ -122,7 +122,7 @@ def imagetypes_getdepends(d):
     return depstr
 
 
-XZ_COMPRESSION_LEVEL ?= "-e -9"
+XZ_COMPRESSION_LEVEL ?= "-e -6"
 XZ_INTEGRITY_CHECK ?= "crc32"
 XZ_THREADS ?= "-T 0"
 
Signature · 1 line
1.7.9.5
#4 lore raw
In reply to Andrei Gherzan

Any volunteers to test this on a system with >4 real cores?

Op 12 jul. 2012, om 20:13 heeft Andrei Gherzan het volgende geschreven:

Quoted 65 lines

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

meta/classes/image_types.bbclass | 5 +++--

1 file changed, 3 insertions(+), 2 deletions(-)
Signature · 1 line
1.7.9.5
#5 lore raw
Quoted 1 line · Koen Kooi

Any volunteers to test this on a system with >4 real cores?

How do you get the memory usage bit?

-M

Quoted 74 lines

Op 12 jul. 2012, om 20:13 heeft Andrei Gherzan het volgende geschreven:

Quoted 59 lines

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

Quoted 6 lines

meta/classes/image_types.bbclass | 5 +++--

1 file changed, 3 insertions(+), 2 deletions(-)

--
1.7.9.5

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#6 lore raw
In reply to Koen Kooi
Quoted 2 lines · Koen Kooi

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?

I will run it on a machine I have, just want to make sure I am doing the same tests that Andrei is running.

I was about to ask what msm asked about the Memory info.

Sau!

Quoted 75 lines

Op 12 jul. 2012, om 20:13 heeft Andrei Gherzan het volgende geschreven:

Quoted 59 lines

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

Quoted 6 lines

meta/classes/image_types.bbclass | 5 +++--

1 file changed, 3 insertions(+), 2 deletions(-)

--
1.7.9.5

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#7 lore raw
Quoted 5 lines · Saul Wold
Quoted 3 lines · Koen Kooi

Any volunteers to test this on a system with >4 real cores?

Quoted 10 lines

Koen,

Does OE-Core or Poky have an image setup for using .xz by default?

I will run it on a machine I have, just want to make sure I am doing the same tests that Andrei is running.

I was about to ask what msm asked about the Memory info.

That field in results is not from "time". It's from gnome-system-monitor. Sorry for being a little confusing.

@g

#8 lore raw
Quoted 7 lines · Andrei Gherzan
Quoted 6 lines · Saul Wold
Quoted 3 lines · Koen Kooi

Any volunteers to test this on a system with >4 real cores?

Quoted 8 lines
Quoted 8 lines

Koen,

Does OE-Core or Poky have an image setup for using .xz by default?

I will run it on a machine I have, just want to make sure I am doing the same tests that Andrei is running.

I was about to ask what msm asked about the Memory info.

use htop

Quoted 10 lines

That field in results is not from "time". It's from gnome-system-monitor. Sorry for being a little confusing.

@g

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#9 lore raw
In reply to Saul Wold

Op 12 jul. 2012, om 21:22 heeft Saul Wold het volgende geschreven:

Quoted 7 lines · Koen Kooi
Quoted 2 lines

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

Quoted 84 lines

I will run it on a machine I have, just want to make sure I am doing the same tests that Andrei is running.

I was about to ask what msm asked about the Memory info.

Sau!

Quoted 75 lines

Op 12 jul. 2012, om 20:13 heeft Andrei Gherzan het volgende geschreven:

Quoted 59 lines

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

Quoted 6 lines

meta/classes/image_types.bbclass | 5 +++--

1 file changed, 3 insertions(+), 2 deletions(-)

--
1.7.9.5

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#10 lore raw
Quoted 9 lines · Koen Kooi

Op 12 jul. 2012, om 21:22 heeft Saul Wold het volgende geschreven:

Quoted 6 lines · Koen Kooi
Quoted 2 lines

Any volunteers to test this on a system with >4 real cores?

Koen,

Quoted 8 lines
Quoted 1 line

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).

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 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).

Adding more threads will multiply that figures.

My 2 cents

Andrea

[1] http://cgit.openembedded.org/openembedded-core/log/meta/classes/image_types.bbclass
[2] http://www.linuxcertif.com/man/1/xz

Quoted 90 lines
Quoted 84 lines

I will run it on a machine I have, just want to make sure I am doing the same tests that Andrei is running.

I was about to ask what msm asked about the Memory info.

Sau!

Quoted 75 lines

Op 12 jul. 2012, om 20:13 heeft Andrei Gherzan het volgende geschreven:

Quoted 59 lines

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

Quoted 6 lines

meta/classes/image_types.bbclass | 5 +++--

1 file changed, 3 insertions(+), 2 deletions(-)

--
1.7.9.5

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#11 lore raw
Quoted 21 lines · Andrea Adami
Quoted 4 lines · Koen Kooi

Op 12 jul. 2012, om 21:22 heeft Saul Wold het volgende geschreven:

Quoted 1 line · Koen Kooi
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

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

:)

Quoted 5 lines

regards,

Koen

Quoted 10 lines

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.

Quoted 5 lines

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?

Quoted 5 lines

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.

Quoted 2 lines

Indeed. With 8GB memory at my disposal i couldn't compress an image with -e -9 and -T 0 (-T 4)/

@g

#12 lore raw
Quoted 29 lines · Andrei Gherzan
Quoted 27 lines · Andrea Adami
Quoted 9 lines · Koen Kooi

Op 12 jul. 2012, om 21:22 heeft Saul Wold het volgende geschreven:

Quoted 6 lines · Koen Kooi
Quoted 2 lines

Any volunteers to test this on a system with >4 real cores?

Koen,

Quoted 9 lines
Quoted 1 line

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.

Quoted 7 lines
Quoted 4 lines

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.

Well, in oe-core maybe.
Upstream they are more conservative, see that man.

"The default preset level in LZMA Utils is -7 while in XZ Utils it is -6, so both use 8 MiB dictionary by default."

Cheers

Andrea

Quoted 31 lines
Quoted 5 lines

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?

Quoted 5 lines

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.

Quoted 2 lines

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

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#13 lore raw
Quoted 9 lines

Well, in oe-core maybe.
Upstream they are more conservative, see that man.

"The default preset level in LZMA Utils is -7 while in XZ Utils it is -6, so both use 8 MiB dictionary by default."

So you were talking about upstream. Ok got that.

@g

Applied
#14 lore raw
In reply to Andrei Gherzan
Quoted 59 lines · Andrei Gherzan

Koen suggested to add -T to xz commands. We have this option implemented in our current version .1alpha.

-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.

-------------------

Memory: 7.8 GiB
Processor:: Intel® Core™ i5-2540M CPU @ 2.60GHz × 4

File to compress: 1.9G

xz -f -k -e -9 --check=crc32 (current configuration)
Memory: 673Mb

real    6m37.170s
user    6m35.389s
sys     0m0.884s

Compressed file size: 3.4Mb

xz -f -k -e -9 -T 4 --check=crc32
Memory: Cannot allocate memory

xz -f -k -e -8 -T 4 --check=crc32
Memory: 1.8G

real    3m24.462s
user    12m8.502s
sys     0m2.180s

Compressed file size: 3.4Mb

xz -f -k -T 4 --check=crc32 (-e defaults to -6)
Memory: 471Mb

real    1m9.265s
user    4m8.972s
sys     0m0.944s

Compressed file size: 3.4Mb

So my conclusion would be to use the default -e -6 with -T 0.

The following changes since commit 90ad663909c0c8a405b22a510c9f957007d02669:

   upstream_tracking: update boost (2012-07-09 17:21:38 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ag/xz
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/xz

Andrei Gherzan (3):
image_types.bbclass: Fix COMPRESS_CMD for xz to redirect compressed
data to file
image_types.bbclass: Add XZ variable to set number of threads to be
used while compressing
image_types.bbclass: Default XZ_COMPRESSION_LEVEL to -e -6

Quoted 3 lines
  meta/classes/image_types.bbclass |    5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

Merged into OE-Core

Thanks
Sau!