Hacker News Reader

Comment by ndesaulniers | Hacker News Reader

I'm impressed. I don't know of too much work that's going on upstream for optimizing boot times, other than some of the clear linux stuff: https://www.phoronix.com/scan.php?page=news_item&px=Clear-Li...

There are folks looking into improving boot times on Android; turns out init and kernel drivers are a tangly mess of {dependency} spaghetti. Loading kernel modules can induce delays in processing relocations.

The kernel patches disable a bunch of stuff, including ethernet it looks like? Most of the kernel changes comment out blocks of code, or trade long delays for shorter delays with more iterations.

View on HN

Yeah, this appears to take advantage of the fact that if you know exactly what hardware you're working with, you can skip a whole lot of detection and general support, which helps quite a bit for embedded but less so on ex. your laptop. Honestly, while there may well be dependency issues, I was under the impression that at least the kernel side of things generally is pretty well optimized, and in most cases you're paying for flexibility.

dracut on RHEL7+ builds the initramfs in "host_only" mode, which attempts to strip it down to just the kernel modules you need for boot time.

Which is also somewhat annoying because it completely trashes portability, which can be really irritating in cloud environments.

Ubuntu has similar capability (and I'm guessing Debian upstream?), but you have to specifically enable it, by default it ships the full modules set in the initramfs.

I would imagine most places outside of embedded world and maybe microvms, this stuff isn't that valuable.

Slight correction: by default Debian/Ubuntu put all modules potentially required for initial boot into the initramfs. That's still a very small percentage of all modules. I.e. you only need those modules that will get you so far into the boot process that you have access to the root partition with all the remaining modules.

E.g. if you want to do network-boot over wifi, you'll have to add a initramfs-hook script to add the wifi modules for your hardware into the initramfs [1]. They are not included by default.

[1] http://www.marcfargas.com/posts/enable-wireless-debian-initr...

You're right, I misinterpreted what "most" meant in the mkinitramfs config. Interesting. I've not seen any difficulties with porting Ubuntu between different hardware configurations, so it seems to include a reasonable amount of them.

Every now and then I'm tempted to try "dep" instead of "most", but then I realise there just isn't enough benefit!

Is there a way to specify when running mkinitramfs whether kernel modules are stored there or not?

Vaguely related: there's Firecracker which boots in 125ms on x86 but that's as a VM, so it's an apples to oranges comparison. From what I recall Firecracker powers AWS Lambda so it's an interesting project in that respect too.

https://firecracker-microvm.github.io/

I know Google cloud VM's are using kexec for faster launches; cause we had some awful toolchain related bugs to fix there. Debugging wasn't very fun, at least on x86 this part of the kernel is called "purgatory" cause there is literally no runtime (not even the kernel's "runtime" is available, mid-kexec).

I remember an article from over a decade ago about booting Linux on an embedded device in 1 second. The key was to modify driver init and bring up the critical stuff first such as disk and graphics and boot user space as fast as possible. Then worry about networking and so on.

I'd imagine that if init tried to use the network before the kernel's networking was initialized, you could deadlock though that'd be considered a bug in the init dependencies. The hard part is even visualizing the dependencies with init is tricky. I don't know if that's something systemd explicitly solves, but I try to stay out of userspace (unless the compiler is borked; narrator: it is)

Reply on news.ycombinator.com