8 May 2023 |
@janne.hess:helsinki-systems.de | ElvishJerricco: oh boy: https://zh.fail/failed/by-maintainer/dasJ.html | 15:58:38 |
Arian | Systemd initrd is 800ms slower than the scripted initrd :( | 15:59:52 |
Arian | On my machine | 15:59:55 |
@elvishjerricco:matrix.org | Janne Heß: https://github.com/NixOS/nixpkgs/pull/230366 | 16:00:57 |
@elvishjerricco:matrix.org | Arian: Yea, I think it's slower on my machines as well | 16:01:36 |
@elvishjerricco:matrix.org | I've always wanted to try to figure out why it's so much slower, but never bothered yet | 16:01:58 |
@elvishjerricco:matrix.org | part of it for sure is that "activation" occurs during initrd instead of stage 2 | 16:02:30 |
@gdamjan:spodeli.org | maybe it's in total just bigger? | 16:02:33 |
@elvishjerricco:matrix.org | so that amount of time is misattributed | 16:02:42 |
@elvishjerricco:matrix.org | gdamjan: I think loading the initrd could only realistically account for like a tenth of a second or something, considering how fast modern CPUs are to decompress ~15MB | 16:04:25 |
Arian | im talking about the total time unfortunately | 16:04:29 |
Arian | stage1+stage2 is 800ms slower | 16:04:34 |
@elvishjerricco:matrix.org | ah | 16:04:38 |
@elvishjerricco:matrix.org | In reply to @elvishjerricco:matrix.org Janne Heß: https://github.com/NixOS/nixpkgs/pull/230366 That PR is definitely not finished though; see the comments. Would appreciate any ideas | 16:05:52 |
@janne.hess:helsinki-systems.de | yeah i see :/ | 16:06:03 |
Arian | systemd:
Startup finished in 751ms (firmware) + 182ms (loader) + 301ms (kernel) + 1.431s (initrd) + 2.077s (userspace) = 4.744s
Startup finished in 757ms (firmware) + 173ms (loader) + 1.577s (kernel) + 1.465s (userspace) = 3.973s
multi-user.target reached after 1.465s in userspace.
| 16:06:52 |
Arian | also interesting. stage 2 is slowertoo | 16:07:40 |
Arian | (I think the stage-1 metric gets folded into kernel ) | 16:07:54 |
@nikstur:matrix.org | ElvishJerricco: Arian https://github.com/NixOS/nixpkgs/pull/230777 In this PR, the definition files for systemd-repart are now stored in the initrd directly. However, sysroot still needs to be mounted. However, I don't really see a way around it. | 22:39:26 |
@nikstur:matrix.org | * ElvishJerricco: Arian https://github.com/NixOS/nixpkgs/pull/230777 In this PR, the definition files for systemd-repart are now stored in the initrd directly. However, sysroot still needs to be mounted and I don't really see a way around it. | 22:46:11 |
@elvishjerricco:matrix.org | nikstur: What Arian and I had discussed before was adding a device option to inform it which device you want it to format. | 22:52:12 |
@elvishjerricco:matrix.org | We thought about trying to derive it from fileSystems."/".device but this wouldn't realistically work | 22:53:35 |
@nikstur:matrix.org | In reply to @elvishjerricco:matrix.org nikstur: What Arian and I had discussed before was adding a device option to inform it which device you want it to format. That seems fair. | 23:00:42 |
@nikstur:matrix.org | In reply to @elvishjerricco:matrix.org We thought about trying to derive it from fileSystems."/".device but this wouldn't realistically work Yes that wouldn't work for a volatile filesystem like a tmpfs for example | 23:01:03 |
@elvishjerricco:matrix.org | the other possibility about is mounting /nix/store in /sysusr to try to get sysusr -style functionality. This is significantly tricker though, and of course doesn't work if the store isn't on the same storage device as the root fs. | 23:02:12 |
@elvishjerricco:matrix.org | * the other possibility is mounting /nix/store in /sysusr to try to get sysusr -style functionality. This is significantly tricker though, and of course doesn't work if the store isn't on the same storage device as the root fs. | 23:02:21 |
@nikstur:matrix.org | I thought about that too. That would also allow us to use systemd-veritysetup-generator which would be fun | 23:03:26 |
@nikstur:matrix.org | We could also think about invoking systemd-repart multiple times one for each disk you want to partition | 23:04:43 |
@nikstur:matrix.org | But as it stands, systemd-repart really only thinks about single-disk systems | 23:06:05 |
@elvishjerricco:matrix.org | nikstur: The most comprehensive thing we could probably do would be to support three modes: 1) Let repart find the device via /sysusr , which would be repurposed for /nix/store . 2) Let repart find the device via /sysroot , meaning you must already have a formatted root fs. 3) Allow specifying the device manually in a NixOS option. | 23:17:39 |