Re: [PATCH 1/2] package_rpm.bbclass: use multithreaded xz compression

[Andre McCurdy <armccurdy@gmail.com>]

On Thu, Jun 1, 2017 at 8:15 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> RPM's default is single-threaded gz; the change greatly helps with
> both buildtimes (when there is a small number of large-sized packages)
> and disk space taken by resulting rpms.

Do you have any test results for that? Obviously build times will be
longer when building with a single CPU since xz compression needs more
CPU than gzip, but I'm curious how many CPUs are required before the
multiple threads win over and build times actually get shorter. 4? 8?

One other concern with parallel xz compression is memory usage. Single
threaded xz needs more memory than gzip and running multiple xz
compression threads together will push the memory usage up again.
Maybe not an issue if the peak is still acceptable, but something to
be aware of (I've given up trying to build in 4GB, but hopefully 8GB
build machines still have some life left in them...).

> Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
> ---
>  meta/classes/package_rpm.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
> index a844c4d4360..dc241975c3b 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -644,6 +644,8 @@ python do_package_rpm () {
>      cmd = cmd + " --define '_build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'"
>      cmd = cmd + " --define '_use_internal_dependency_generator 0'"
>      cmd = cmd + " --define '_binaries_in_noarch_packages_terminate_build 0'"
> +    cmd = cmd + " --define '_binary_payload w6T.xzdio'"
> +    cmd = cmd + " --define '_source_payload w6T.xzdio'"
>      if perfiledeps:
>          cmd = cmd + " --define '__find_requires " + outdepends + "'"
>          cmd = cmd + " --define '__find_provides " + outprovides + "'"
> --
> 2.11.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core