All of lore.kernel.org
 help / color / mirror / Atom feed
From: "André Almeida" <andrealmeid@igalia.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
	kernel-dev@igalia.com, Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nicolas Schier <nicolas@fjasle.eu>
Subject: Re: [PATCH] kbuild: modinst: Enable multithread xz compression
Date: Fri, 24 Feb 2023 09:12:12 -0300	[thread overview]
Message-ID: <cadf9320-366c-da33-5fb4-30575533b04e@igalia.com> (raw)
In-Reply-To: <CAK7LNAQbzWQs3WzsdyLsCyFD_2Kgz8sqjqk+nFXkEXQFrYobRA@mail.gmail.com>

Hi Masahiro,

Em 24/02/2023 02:38, Masahiro Yamada escreveu:
> On Thu, Feb 23, 2023 at 9:17 AM André Almeida <andrealmeid@igalia.com> wrote:
>>
>> As it's done for zstd compression, enable multithread compression for
>> xz to speed up module installation.
>>
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> ---
>>
>> On my setup xz is a bottleneck during module installation. Here are the
>> numbers to install it in a local directory, before and after this patch:
>>
>> $ time make INSTALL_MOD_PATH=/home/tonyk/codes/.kernel_deploy/ modules_install -j16
>> Executed in  100.08 secs
>>
>> $ time make INSTALL_MOD_PATH=/home/tonyk/codes/.kernel_deploy/ modules_install -j16
>> Executed in   28.60 secs
> 
> 
> Heh, this is an interesting benchmark.
> 
> Without this patch, you ran 16 processes of 'xz' in parallel
> since you gave -j16.
> 
> You created multi-threads in each xz process, then you got 3x faster.
> What made it happen?
> 
> 

During the modules installation in my setup, the build system would 
spend most of it's time compressing big modules (such as the 350M 
amdgpu.ko) in a single thread, with 15 idles threads. Enabling 
multithread allowed amdgpu to be compressed really fast.

The real performance improvement during modules compression is not 
compressing as many small modules as possible in parallel, but 
compressing the big ones in multithread, that proved to be the 
bottleneck in my setup.

 > How many threads can your system run?

$ nproc
16

> 
> I did not get such an improvement in my testing.
> In my machine $(nproc) is 24.
> 
> 
> [Without this patch]
> 
> $ time make INSTALL_MOD_PATH=/tmp/inst1  modules_install -j$(nproc)
> 
> real 0m33.965s
> user 10m6.118s
> sys 0m37.231s
> 
> [With this patch]
> 
> $ time make INSTALL_MOD_PATH=/tmp/inst1  modules_install -j$(nproc)
> 
> real 0m32.568s
> user 10m4.472s
> sys 0m39.132s
> 
> 

I can see that my patch did not introduce performance regressions to 
your setup, at least.

> 
> Given that GNU Make provides the parallel execution environment,
> you can control the number of processes of 'xz'.
> 
> There is no point in forcing multi-threading, which the user
> did not ask or ever want.
> 
> 

Should we drop -T0 from zstd then? Is currently forcing multi-threading.

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> ---
>>   scripts/Makefile.modinst | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
>> index 4815a8e32227..28dcc523d2ee 100644
>> --- a/scripts/Makefile.modinst
>> +++ b/scripts/Makefile.modinst
>> @@ -99,7 +99,7 @@ endif
>>   quiet_cmd_gzip = GZIP    $@
>>         cmd_gzip = $(KGZIP) -n -f $<
>>   quiet_cmd_xz = XZ      $@
>> -      cmd_xz = $(XZ) --lzma2=dict=2MiB -f $<
>> +      cmd_xz = $(XZ) --lzma2=dict=2MiB -f -T0 $<
>>   quiet_cmd_zstd = ZSTD    $@
>>         cmd_zstd = $(ZSTD) -T0 --rm -f -q $<
>>
>> --
>> 2.39.2
>>
> 
> 

Thanks,
André Almeida

  reply	other threads:[~2023-02-24 12:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23  0:16 [PATCH] kbuild: modinst: Enable multithread xz compression André Almeida
2023-02-23 20:16 ` Nathan Chancellor
2023-02-24  5:38 ` Masahiro Yamada
2023-02-24 12:12   ` André Almeida [this message]
2023-02-25 10:21     ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cadf9320-366c-da33-5fb4-30575533b04e@igalia.com \
    --to=andrealmeid@igalia.com \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.