You can thank the tape deck storage posts on the forum for this idea. So, when reading the disk during boot, I’m sure it is jumping all around. My thought is to record the files that are accessed and rearrage the whole root file layout based on that record to allow total sequential access to increase performance. One could copy the root partition to a tape, and get over 250 MB/s. I’m sure it would be unusable without rearranging the data.
I am also wanting to create a raid, but that will have to wait, unless I can unmount the root filesystem safely. I don’t currently have a means to boot gparted without pxe boot, which I don’t know how to setup and would rather avoid if it is many steps.
1 Like
Pretty sure one of the benefits of UEFI booting, is that the bootloader can multithread loading several resources in parrallel, while some threads are held back waiting for others to complete / load.
IIRC, the init ram fs form Linux, is about as fast as you’re gonna get.
best use flash for the random access, with resources beign called as tasks complete
but, I could be wrong.
pretty sure NVMe throughput beats tape anyway?
so, much better to avoid the hassle, and just use NVMe.
The largest chunk of time is probably getting Gnome loaded.
I think Windows cheats, and suspends the ram to flash, instead of properly closing down, but default (“fast boot”)
I presume one can suspend in Linux, but would not be surprised if the network module becomes unresponsive on wake, or some other such silliness.
I never really looked into it, just from what I think I remember is all
2 Likes
KDE is still quite slow, even over a decade since the v4 era. I tried disabling some kde services, but some are incredibly useful like the abrt program which notifies of system issues like filesystems not responding, or if a program did not close correctly etc. I do notice root user is 10x faster, not an exageration, so maybe there is something I can reset.
If I really want the system faster I’ll start a different desktop. I do like KDE and all of its tools, just much slower then other desktops or window managers.
1 Like
I use mate, and just presumed gnome was the most bloated. Kinda glad KDE can get slow…
regarding speed of root, yeah, makes sense with fewer user programs, caches, settings and “tweaks”
though to be fair, I’ve only used it in VM’s, and it’s been pretty fast. I don’t spend much time customising / installing much in VM’s though
To be fair, I mostly use just plain old sata SSD’s to boot from, so am presuming NVMe would bump the speed a bit, but even then, I also never bothered changing up, because the bump was not worth buying smaller NVMe sticks, when slots are few and precious, where sata can expand much easier.
(aka, “not on my machine”, which does not really help you too much, sorry)
Protip - measure first and then experiment. Systemd-analyze is your friend.
Playing around with data structures to guarantee sequential load seem like monumentally hard task for very little potential gain. Especially when even basic ssd level of random read performance makes it pointless.
Even with 10 year old hardware and mainstream ssd its dead easy to achieve <10s from power to desktop and even less with manual tinkering. I managed to achive <6,5s from power to desktop on older zenbook model.
Fedora 23 (Twenty Three) zenbook (Linux 4.3.3-303.fc23.x86_64 #1 SMP Tue Jan 19 18:31:55 UTC 2016) x86-64
Startup finished in 1.619s (firmware) + 510ms (loader) + 1.243s (kernel) + 2.645s (userspace) = 6.018s
All that by removing some blocking or useless service + skiping initrd.
Paradoxically, its much harder nowadays thank to variable uefi complexity and level of control. My AM5 board takes longer to reach even bootloader stage than that old ass zenbook took to to get directly to desktop.
Dell XPS notebook? Entirely pointless to optimize, since uefi stage alone takes 10s+ no matter the actual settings applied.
Anyway ,start with systemd-analyze output and make notes. Reference here.
- how long do you spend in uefi (firmware)?
- how much in bootloader?
- how much in spent in initrd and can you skip it? Yes, you can change the boot options and specify root partition by uuid
- what system services create critical boot chain and which ones of them YOU do not need? Do any of them spend whole lot of time waiting and then end in timeout?
1 Like
TIL about SystemD Analyze, thank you.
One more addendum, there is complementary and older utility called bootchart.
It performs boot time performance profiling a thus gives you lovely overview, if there are any HW bottlenecks during boot.
It must be actively configured beforehand in init or interactively invoked by editing boot parameters, and it also incurs measurable performance penalty in low performance systems, so make a comparison of the result boot times. It should not matter nowadays, but it maybe in embedded environments its still applies.
It can also be invoked on demand during runtime, but I haven used that.
Nowadays it has been merged into systemd, so availability should be ubiquitous.
Links and personal example: