You are not logged in.
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)
Offline
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)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
11875ms (initramfs) means the time it takes you to type the password.
Offline
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.
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.
Offline
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...
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
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)
Offline
But the OP posted times which did distinguish initramfs from kernel despite not having timestamp the list of hooks. That confuses me.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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)
Offline
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.
Offline