[OE-core] [PATCH] populate_sdk_base: use xz -T instead of pixz

Khem Raj raj.khem at gmail.com
Mon Apr 9 21:20:22 UTC 2018


On Mon, Apr 9, 2018 at 1:44 PM, Burton, Ross <ross.burton at intel.com> wrote:
> On 9 April 2018 at 21:13, Andre McCurdy <armccurdy at gmail.com> wrote:
>> On Mon, Apr 9, 2018 at 8:19 AM, Ross Burton <ross.burton at intel.com> wrote:
>>> xz has native support for threaded compression now and SDK creation was the only
>>> part of oe-core which is using pixz instead of xz.
>>>
>>> Not only does this remove pixz-native from the SDK dependencies, but in my
>>> limited testing xz -T0 is slightly faster and produces smaller archives than
>>> pixz for the same input.
>>>
>>> Signed-off-by: Ross Burton <ross.burton at intel.com>
>>> ---
>>>
>>>  # We want the MULTIARCH_TARGET_SYS to point to the TUNE_PKGARCH, not PACKAGE_ARCH as it
>>> @@ -225,7 +225,7 @@ fakeroot tar_sdk() {
>>>         # Package it up
>>>         mkdir -p ${SDKDEPLOYDIR}
>>>         cd ${SDK_OUTPUT}/${SDKPATH}
>>> -       tar ${SDKTAROPTS} -cf - . | pixz > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.tar.xz
>>> +       tar ${SDKTAROPTS} -cf - . | xz -T 0 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.tar.xz
>>
>> Since -T 0 will use all available CPUs (ie any attempts the user may
>> have made to limit parallelism via BB_NUMBER_THREADS or PARALLEL_MAKE
>> will be ignored), perhaps it's worth adding something like
>> "--memlimit=70%" to try to give some protection for environments with
>> lots of CPUs but not so much DRAM?
>
> There's a few places where -T0 is passed already: tar.xz image
> creation and opkg creation, so I guess we need to centralise this
> somewhere too.
>

May be use XZ_OPT env bariable and param to -T could use the bitbake
calculated number of CPUs

> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



More information about the Openembedded-core mailing list