Re: [arch-general] Multi-threaded mkinitpcio

[Pascal via arch-general]

hi,

change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf
: it will considerably reduce the compression time.

grep COMP /etc/mkinitcpio.conf
# COMPRESSION
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
COMPRESSION="lz4"
# COMPRESSION_OPTIONS
#COMPRESSION_OPTIONS=()

see here

for quick  benchmarks...

regards, lacsaP.

Le ven. 3 avr. 2020 à 08:08, Ralf Mardorf via arch-general <
arch-general@archlinux.org> a écrit :

> On Fri, 3 Apr 2020 04:36:37 +0200, mpan wrote:
> >Half of the time mkinitcpio was waiting for disk I/O.
>
> Even while it's unlikely that only mkinitcpio suffers from a damaged
> HDD and even while smartctl not necessarily does show issues of a
> already damaged aged HDD, I would run smartctl and take a look, if it
> shows something fishy.
>

Re: [arch-general] Multi-threaded mkinitpcio

[Ralf Mardorf via arch-general]

On Fri, 3 Apr 2020 04:36:37 +0200, mpan wrote:
>Half of the time mkinitcpio was waiting for disk I/O.

Even while it's unlikely that only mkinitcpio suffers from a damaged
HDD and even while smartctl not necessarily does show issues of a
already damaged aged HDD, I would run smartctl and take a look, if it
shows something fishy.

Re: [arch-general] Multi-threaded mkinitpcio

[mpan]

> Actually this 2 minutes bothers me this much that I'm emailing Arch
> General Mailing List is because I'm afraid my Arch would be broken if my
> laptop shuts down in this process and I have to rescue it by live USB.
  For nearly a decade of using this particular Arch installation alone,
I never had a single case of losing power while mkinitcpio was running.
I wouldn’t be afraid of that scenario. And laptops are better than my PC
in that manner, because you have backup power from the battery.

> Does it help if it gets executed over multi threads or the bottleneck is
> somewhere else?
  For my particular setup, running `mkinitcpio -P` yields those times:

real1m8.320s
user0m24.742s
sys 0m12.806s

Half of the time mkinitcpio was waiting for disk I/O. Most likely
`find`, but that’s only mu guess.

  This is only a single computer. Unlike modern laptops it uses spinning
rust for storage, but OTOH it is also running a CPU that remembers 2000s
and DDR2-800 RAM. So both would affect the outcome.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Multi-threaded mkinitpcio

[Giancarlo Razzolini via arch-general]

Em abril 2, 2020 22:28 Amin Vakil escreveu:

So every update of linux kernels and modules which need mkinitpcio to be
executed, takes too much unnecessary time (maybe 2 min) which could be
handled if it executes on multi threads of CPU.



Which compression algorithm are you using?


Actually this 2 minutes bothers me this much that I'm emailing Arch
General Mailing List is because I'm afraid my Arch would be broken if my
laptop shuts down in this process and I have to rescue it by live USB.



As it's true for pretty much all update process for pretty much every OS
in the world, things can break if the update is interrupted.



So my question is why it doesn't execute over all threads or at least
have the option to do that?



mkinitcpio is a bunch of scripts copying files to a temporary dir and then
compressing the result afterwards. I bet most of this time you're seeing is
on compression's fault, not mkinicpio itself.


Does it help if it gets executed over multi threads or the bottleneck is
somewhere else?



Depending on the compression algorithm, reproducibility might not work if
it's using multiple threads. Also, I see multiple issues that could happen
if the build hooks ran out of order.

Regards,
Giancarlo Razzolini

pgpPId6xm3A5S.pgp
Description: PGP signature

[arch-general] Multi-threaded mkinitpcio

[Amin Vakil]

So every update of linux kernels and modules which need mkinitpcio to be
executed, takes too much unnecessary time (maybe 2 min) which could be
handled if it executes on multi threads of CPU.

Actually this 2 minutes bothers me this much that I'm emailing Arch
General Mailing List is because I'm afraid my Arch would be broken if my
laptop shuts down in this process and I have to rescue it by live USB.

I have read the mkinitpcio wiki page and I can't find anything regarding
this matter:
https://wiki.archlinux.org/index.php/Mkinitcpio

I've checked and my cpu usage and it shows me that it uses maximum power
of a core when mkinitpcio is running, so I assumed it could be helped if
it runs on multi threads.

So my question is why it doesn't execute over all threads or at least
have the option to do that?

Does it help if it gets executed over multi threads or the bottleneck is
somewhere else?



signature.asc
Description: OpenPGP digital signature

[arch-general] TexLive 2020 packages

[Rémy Oudompheng via arch-general]

Hello,

TexLive 2020 is frozen upstream and will be officially released in the
coming days.
Packages have been uploaded to [testing] and [community-testing] (for biber).

Please let me know if you encounter issues with these.

Regards,
Rémy.