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
> 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
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
for xz (the line with | $compress)
total run time for 2 kernels is
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
(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?
I found that another 28% (2.95s per kernel) is spent
on the section "Including module"
Hm, is the part loading dracut modules?