On Wed, 13 Jan 2021 16:16:01 +0100, Bernhard M. Wiedemann wrote:
On 13/01/2021 15.41, Takashi Iwai wrote:
On Wed, 13 Jan 2021 14:57:06 +0100, Marcus Meissner wrote:
On Wed, Jan 13, 2021 at 01:53:36PM +0000, Michael Schroeder wrote:
On Wed, Jan 13, 2021 at 02:43:00PM +0100, Stephan Kulow wrote:
Well, you can still serialze the scriplet part and parallelize the payload uncompression and file installation
Maybe, but somewhat should first take a look where all the time is spent in the rpm installation code. Maybe uncompression is just 10% and file system operation is 70%. Or the other way round. Or maybe it's the fsync() on the database?
It is the dracut initrd regeneration for me actually, even on SSD it takes *minutes* :).
That's a long-standing pain, yeah. Did anyone profile the dracut operation to point out what takes so long? I know xz takes quite some time, but it's not dominant, I guess.
On 15.2 I prefixed some commands with /usr/bin/time -p to get
for cpio: real 4.06 user 0.05 sys 0.13
for xz (the line with | $compress) real 4.18 user 4.14 sys 0.02
total run time for 2 kernels is real 0m20.917s user 0m17.552s sys 0m3.835s
so the compression alone takes 40% of the total time.
Thanks, that's an interesting number. An easier option would be to parallelize the compression. How does the number change if you add -P4 or whatever to compress=... line in /usr/lib/dracut.conf.d/01-dist.conf? (Or override in /etc/dracut.conf.d/...) And cpio takes also so long... It's no CPU-bound, and it's waiting for the inputs?
Using date '+%s.%N' I found that another 28% (2.95s per kernel) is spent on the section "Including module"
Hm, is the part loading dracut modules? Takashi