I'd really like to get my raspberry pi booting in a couple seconds. I have a few ideas for things I'd like to try but the boot time is too long. Don't need X11 but I would like to use raspbian.
Linux Kernel Fastboot [pdf]
51–60 of 121 posts
Re: Linux Kernel Fastboot [pdf]
#52I'd really like to get my raspberry pi booting in a couple seconds. I have a few ideas for things I'd like to try but the boot time is too long. Don't need X11 but I would like to use raspbian.
The Pi 4 is definitely much faster on boot. I wonder how much of your bottleneck is the SD read speed, though.
Re: Linux Kernel Fastboot [pdf]
#53Re: Linux Kernel Fastboot [pdf]
#54> Systemd is ~1.5MB - the loading time for emmc is 100ms Surely not all of systemd is faulted in immediately, is this really an issue?
If you want just the important parts faulted in, you need to get the important parts into their own pages, preferably in order. I don’t know whether profile-guided linking is a thing.
In /proc/1/smaps, I find the following executable mapping:
55aa05f89000-55aa06076000 r-xp 00000000 fd:01 1823 /lib/systemd/systemd
Size: 948 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 752 kB
Pss: 489 kB
Shared_Clean: 504 kB
Shared_Dirty: 0 kB
Private_Clean: 248 kB
Private_Dirty: 0 kB
Referenced: 740 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw
So it appears 740KiB has been referenced, 752KiB resident.There's also the read-only mapping:
55aa06076000-55aa0609b000 r--p 000ec000 fd:01 1823 /lib/systemd/systemd
Size: 148 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 148 kB
Pss: 74 kB
Shared_Clean: 0 kB
Shared_Dirty: 148 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 148 kB
Anonymous: 148 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me dw ac
Another 148KiB, so 900KiB, a good chunk of the 1.1MiB - though this is with a substantial uptime.The really disgusting part is all the dependencies; `pmap 1` says 57MiB total, and there's not much anonymous memory to blame.
Re: Linux Kernel Fastboot [pdf]
#55I love the bit on slide 16 where initializing 8GB of RAM takes 100MS, so they boot with only 2GB and then hotplug in more memory later.
There was a bug in a proposed kernel patch a while back, that we were testing. It ended up designating a good chunk of the machine's RAM as hotpluggable. Test suite was passing, but the benchmarks showed a drastic performance drop. Took a while to track down why that was happening.
Re: Linux Kernel Fastboot [pdf]
#56How nostalgic! Mind you, I say that in a good way! This brings me back to the heydays of Sun Microsystems where they controlled both the hardware (SPARC) and the operating system (Solaris). Sun didn't hesitate to use this to their advantage. With Clear Linux, I see Intel doing some very similar things. Yes, this was just a story about boot time, but it led me to take a look at Clear Linux and it looks like it could b…
I'd urge some caution. It depends on your use case and the accuracy requirements you have. Clear Linux gets a chunk of its speed boosts by using compiler optimisations that most distributions won't touch because of the possibility they'll reduce accuracy and move outside the bounds of various standards, e.g. --ffast-math. Clear Linux also sets it so that by default when you go to compile stuff, it ends up picking up their "optimised" set of compiler flags too.
It works, it's fine, it's fast. Just make sure you know what you're getting and what the consequences for your software might be (I'm sure most people _don't_ have strict IEEE standards to care about, for example)
Re: Linux Kernel Fastboot [pdf]
#57Earlier quoted context omitted.
2gb user + 2gb kernel?
2 gb user + 1 gb swap + 1 gb rootfs unpacked in ram perhaps. They discuss a decompression operation and the only portion of the sequence that would occur in normally is unpacking a rootfs in RAM.
And in this case they don't appear to be using any initrd for the root filesystem, just hurrying to bring up access to the full filesystem over eMMC.
Re: Linux Kernel Fastboot [pdf]
#58> Systemd is ~1.5MB - the loading time for emmc is 100ms Surely not all of systemd is faulted in immediately, is this really an issue?
If you want just the important parts faulted in, you need to get the important parts into their own pages, preferably in order. I don’t know whether profile-guided linking is a thing.
―
¹ At least on GCC but I would be very surprised if clang doesn't also do this.
² You can also do this manually with __attribute__((hot)) and __attribute__((cold))
Re: Linux Kernel Fastboot [pdf]
#59How nostalgic! Mind you, I say that in a good way! This brings me back to the heydays of Sun Microsystems where they controlled both the hardware (SPARC) and the operating system (Solaris). Sun didn't hesitate to use this to their advantage. With Clear Linux, I see Intel doing some very similar things. Yes, this was just a story about boot time, but it led me to take a look at Clear Linux and it looks like it could b…
Clear Linux is blazing fast (compiled with Intel compilers), and supposedly has a strong security model -- but it also has an extremely limited package selection. To the point that it's just not usable for me. Also, its package manager forces you to install "bundles" of somewhat related packages rather than just the specific packages you want and their deps. Maybe I'm missing something, but I find this very odd.
This is a common misconception. It's not built with ICC, it's built with GCC (and some parts maybe with Clang).
When did you try Clear? They have about 6200 packages now, but I'm not sure if that's still "limited" in relative terms.
Re: Linux Kernel Fastboot [pdf]
#60> Rootfs Mouting -> Rootfs Mounting ?