Live data from Hacker News

Linux Kernel Fastboot [pdf]

linuxplumbersconf.org

51–60 of 121 posts

Re: Linux Kernel Fastboot [pdf]

#51

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.

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]

#52

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.

The Pi 4 is definitely much faster on boot. I wonder how much of your bottleneck is the SD read speed, though.

Yes, I'm getting around 10-15 secs boot time for a headless raspbian. I'm sure it could be made even faster with a lightweight application specific distro.

Re: Linux Kernel Fastboot [pdf]

#54
post #50

> 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.

On my long-running debian box, /lib/systemd/systemd is 1.1MiB in size.

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]

#55

I 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 are some drawbacks to that. Memory flagged as hotplug can't be used by the kernel itself (because otherwise unplugging the RAM would risk crashing the system). That includes things like network buffers and a number of things which use the total RAM size as a guideline.

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]

#56
post #4

How 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…

> Until now, Clear Linux wasn't even on my radar. Today, it is. Anyone have some experiences with this distro (for better or worse) that they'd like to share?

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]

#57
post #28

Earlier 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.

The kernel itself is compressed, and among the first things that happen after the bootloader hands off to the kernel is that the stub at the beginning of the kernel decompresses the rest of the kernel.

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
post #50

> 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.

PGO detects hot/cold functions and places them together¹ ², but I imagine whatever it needs on startup is probably not especially hot. …Though it might all be cold, which would have the same effect, actually.

¹ 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]

#59
post #40
post #4

How 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.

> compiled with Intel compilers

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.

Post reply on HN