[SOLVED] initramfs takes too long to load

nasosnik · 2013-01-20 11:19:55

Using systemd-analyze I found out that initramfs takes too long to load:
463ms (kernel) + 11875ms (initramfs) + 6014ms (userspace) = 18353ms

My HOOKS array in mkinitcpio.conf is the following:

HOOKS="base udev autodetect modconf block encrypt lvm2 filesystems usbinput fsck"

I suspect that the long loading time of initramfs is caused by partitions decryption (I am using dm-crypt / LUKS on top of LVM).
Is there any tool that can report loading times of HOOKS seperately, just like systemd-analyze plot does for userspace?

Last edited by nasosnik (2013-01-21 14:45:28)

cfr · 2013-01-20 20:12:29

In what sense is it "too long"?

I'm just wondering: suppose that you find out that it is because you are using encryption. Would you then switch to a non-encrypted system? Would you make better use of the extra seconds you might save on those rare occasions when you reboot? Even if you reboot twice a day, you might save what? Suppose you would even save 5s per boot. That will give you a whole extra 1 minute and 10 seconds a week. Assuming you don't multitask. Obviously if you multitask, the gain will be less. Would that make it worth risking the security of your data?

EDIT: I didn't mean this to sound as confrontational as it does now I read it back. It just always puzzles me that people are so concerned about shaving a few milliseconds here and there. I always hope that they put the time they save to good use but then I realise that the time they spent shaving the milliseconds off will obviously outstrip the time saved.

Last edited by cfr (2013-01-20 20:16:58)

roentgen · 2013-01-20 20:57:54

11875ms (initramfs) means the time it takes you to type the password.

nasosnik · 2013-01-20 21:17:06

cfr wrote:

In what sense is it "too long"?
I'm just wondering: suppose that you find out that it is because you are using encryption. Would you then switch to a non-encrypted system? Would you make better use of the extra seconds you might save on those rare occasions when you reboot? Even if you reboot twice a day, you might save what? Suppose you would even save 5s per boot. That will give you a whole extra 1 minute and 10 seconds a week. Assuming you don't multitask. Obviously if you multitask, the gain will be less. Would that make it worth risking the security of your data?
EDIT: I didn't mean this to sound as confrontational as it does now I read it back. It just always puzzles me that people are so concerned about shaving a few milliseconds here and there. I always hope that they put the time they save to good use but then I realise that the time they spent shaving the milliseconds off will obviously outstrip the time saved.

I really don't care about the boot time because of the reasons you have already mentioned. I just want to figure out if there is any misconfiguration. I am just investigating why initramfs takes significant longer to load compared with my desktop Arch installation (non-encrypted) 1316ms for initramfs. My desktop has a Pentium 4 CPU and laptop has a quad-core i7.

roentgen wrote:

11875ms (initramfs) means the time it takes you to type the password.

systemd-analyze is not counting the time is spent to type the password.

cfr · 2013-01-20 21:26:37

Oh, fair enough. I get (with encryption):

Startup finished in 2104ms (kernel) + 24736ms (initrd) + 30065ms (userspace) = 56907ms

Whereas when I first used systemd (without encryption):

$ systemd-analyze 
Startup finished in 7458ms (kernel) + 31309ms (userspace) = 38768ms

I'm surprised that systemd-analyze gives you those results without timestamp in your modules array in mkinitcpio.conf. I thought that was needed to get a separate timing for initrd. I currently have:

HOOKS="base udev autodetect modconf block encrypt lvm2 resume filesystems usbinput fsck timestamp shutdown"

Of course, I've changed a bunch of things in addition to switching to encryption and the system has been upgraded etc. etc. Still...

roentgen · 2013-01-20 21:39:41

nasosnik wrote:

roentgen wrote:
11875ms (initramfs) means the time it takes you to type the password.
systemd-analyze is not counting the time is spent to type the password.

Are you sure? I just checked and I got 55 seconds for initrd because I actually waited that long to type the password.

65kid · 2013-01-20 22:02:24

yes, the time it takes for you to input your password is (indirectly) counted by systemd-analyze as well.
if you have the timestamp hook, systemd-analyze can differ between the time the kernel itself needs and the time the initramfs needs. If you don't, it will count both as the kernel time. Note that at this point sytemd is not even running yet, it only calculates this stuff based on the timestamps provided by the kernel / the timestamp hook.
systemd itself doesn't know what is happening in the initramfs, so there is no way to display "per-hook"-times. This is something mkinitcpio would have to support and afaik doesn't.

Last edited by 65kid (2013-01-20 22:03:31)

cfr · 2013-01-20 22:14:05

But the OP posted times which did distinguish initramfs from kernel despite not having timestamp the list of hooks. That confuses me.

falconindy · 2013-01-20 23:04:48

nasosnik wrote:

systemd-analyze is not counting the time is spent to type the password.

Uh, it absolutely is. What makes you think otherwise? How do you expect systemd to be capable of differentiating time spent blocking for user input versus time spent running other programs when systemd itself isn't even running? Timestamps are roughly recorded as follows:

kernel time: monotonic clock time when systemd-timestamp is called in the initramfs
initramfs time: monotonic clock time when systemd starts as PID 1, minus kernel time
userspace time: monotonic clock time when all jobs in the initial transaction have been dispatched, minus initramfs and kernel time

Note that the timestamp hook isn't really a necessity. You can just as well add the systemd-timestamp binary yourself to your image.

Last edited by falconindy (2013-01-20 23:05:28)

nasosnik · 2013-01-21 08:31:24

cfr wrote:

But the OP posted times which did distinguish initramfs from kernel despite not having timestamp the list of hooks. That confuses me.

I indeed have the timestamp HOOK at mkinitcpio.conf, I just did not include it at my previous post because I thought it is implied since I am posting initramfs load time.

Arch Linux

#1 2013-01-20 11:19:55

[SOLVED] initramfs takes too long to load

#2 2013-01-20 20:12:29

Re: [SOLVED] initramfs takes too long to load

#3 2013-01-20 20:57:54

Re: [SOLVED] initramfs takes too long to load

#4 2013-01-20 21:17:06

Re: [SOLVED] initramfs takes too long to load

#5 2013-01-20 21:26:37

Re: [SOLVED] initramfs takes too long to load

#6 2013-01-20 21:39:41

Re: [SOLVED] initramfs takes too long to load

#7 2013-01-20 22:02:24

Re: [SOLVED] initramfs takes too long to load

#8 2013-01-20 22:14:05

Re: [SOLVED] initramfs takes too long to load

#9 2013-01-20 23:04:48

Re: [SOLVED] initramfs takes too long to load

#10 2013-01-21 08:31:24

Re: [SOLVED] initramfs takes too long to load

Board footer