[PATCH] classes/populate_sdk_base: Implement xz compression options

[PATCH] classes/populate_sdk_base: Implement xz compression options

[Mike Looijmans]

Building an SDK on a machine with 8GB RAM resulted in excessive swapping
due to the xz compressor using ~20GB of memory. This is because xz is
being called with "-T 0 -9".

To allow tuning the compression versus memory usage, introduce a variable
named SDK_XZ_OPTIONS that defaults to a more sane default:
SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
Thus, inherit any XZ tuning already done, and allow users to specify
overrides for this task in their config by supplying SDK_XZ_OPTIONS.
Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard
behavior.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
 meta/classes/populate_sdk_base.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass
index d03465b6fc..13247e42e5 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -48,6 +48,7 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
 
 # Default archived SDK's suffix
 SDK_ARCHIVE_TYPE ?= "tar.xz"
+SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
 
 # To support different sdk type according to SDK_ARCHIVE_TYPE, now support zip and tar.xz
 python () {
@@ -58,7 +59,7 @@ python () {
        d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip -r ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
     else:
        d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native')
-       d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
+       d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
 }
 
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-- 
2.17.1

Re: [PATCH] classes/populate_sdk_base: Implement xz compression options

[Adrian Bunk]

On Wed, Mar 18, 2020 at 01:21:56PM +0100, Mike Looijmans wrote:
> Building an SDK on a machine with 8GB RAM resulted in excessive swapping
> due to the xz compressor using ~20GB of memory. This is because xz is
> being called with "-T 0 -9".
> 
> To allow tuning the compression versus memory usage, introduce a variable
> named SDK_XZ_OPTIONS that defaults to a more sane default:
> SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
> Thus, inherit any XZ tuning already done, and allow users to specify
> overrides for this task in their config by supplying SDK_XZ_OPTIONS.
> Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard
> behavior.
>...
> +SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"

A problem is that XZ_COMPRESSION_LEVEL compression would now be used for 
unrelated usecases, and lowering the compression for being able to boot
on low-end targets (<= 64 MB RAM) shouldn't impact the SDK.

>...
> -       d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
> +       d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
>...

Replacing "-T 0" with ${XZ_DEFAULTS} should solve your problem.
This already takes both cpus and memory into account.

cu
Adrian

Re: [PATCH] classes/populate_sdk_base: Implement xz compression options

[Mike Looijmans]

On 19-03-2020 12:37, Adrian Bunk wrote:
> On Wed, Mar 18, 2020 at 01:21:56PM +0100, Mike Looijmans wrote:
>> Building an SDK on a machine with 8GB RAM resulted in excessive swapping
>> due to the xz compressor using ~20GB of memory. This is because xz is
>> being called with "-T 0 -9".
>>
>> To allow tuning the compression versus memory usage, introduce a variable
>> named SDK_XZ_OPTIONS that defaults to a more sane default:
>> SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
>> Thus, inherit any XZ tuning already done, and allow users to specify
>> overrides for this task in their config by supplying SDK_XZ_OPTIONS.
>> Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard
>> behavior.
>> ...
>> +SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
> 
> A problem is that XZ_COMPRESSION_LEVEL compression would now be used for
> unrelated usecases, and lowering the compression for being able to boot
> on low-end targets (<= 64 MB RAM) shouldn't impact the SDK.

Clear. I wasn't aware that this was for the targets...

> 
>> ...
>> -       d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
>> +       d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
>> ...
> 
> Replacing "-T 0" with ${XZ_DEFAULTS} should solve your problem.
> This already takes both cpus and memory into account.

I'd still want to have control over that -9 though.

It's not worth it to spend 15 minutes compressing just a few megabytes 
better in a development environment.


-- 
Mike Looijmans