boots

Last Updated on April 25, 2023

Use bootchart to analyze boot times of systemd and SysV init

Objectives

This post shows you how to use bootchart to compare the boot time of systemd and SysV init.

Prerequisites

It might help to better understand the measurements performed here after reading the first and the second part of my Prelink article series.

Bootchart Graphs

The graphs below show various boot time differences between

  • SysV init and systemd
  • cross-prelink enabled or disabled
  • PIE enabled or disabled
    • if PIE is enabled cross-prelink does not work

If we look at the possible combinations we’ll come up at least with four times four graphs:

  • prelink disabled – PIE disabled
    • SysV init – booting for the first time
    • SysV init – not booting for the first time
    • systemd – booting for the first time
    • systemd – not booting for the first time
    • Note: PIE adds an overhead
      • Will we be able to see this somewhere?

  • prelink – with PIE
    • SysV init – booting for the first time
    • SysV init – not booting for the first time
    • systemd – booting for the first time
    • systemd – not booting for the first time
    • Note: prelink does not work due to PIE
      • Will we be able to see this somewhere?

  • prelink deactivated – with PIE
    • SysV init – booting for the first time
    • SysV init – not booting for the first time
    • systemd – booting for the first time
    • systemd – not booting for the first time
    • Note: PIE adds an overhead
      • Will we be able to see this somewhere?

  • prelink – PIE disabled
    • SysV init – booting for the first time
    • SysV init – not booting for the first time
    • systemd – booting for the first time
    • systemd – not booting for the first time
    • Note: This is the only configuration where prelink has a chance to work
      • Will we be able to see this somewhere?

With “sysv-init” it took the first time 52.5 seconds until “grafana” started compared to 39.6 seconds the second time around. This means the first time it took 33% longer, or the second time 25% less, which is significant.

“Systemd” took the first time 36.5 seconds and 33.9 seconds the second time to start “grafana”. This means 8% slower or 7% faster.

In any case, when you boot the system the first time additional tasks are executed which delay the boot process and “systemd” seems to be faster than “sysv-init”.

With “sysv-init” it took the first time 66.5 seconds until “grafana” started compared to 39.8 seconds the second time around. This means the first time it took 67% longer, or the second time 40% less, which is significant. Looks like this is the worst of both worlds.

“Systemd” took the first time 35.6 seconds and 35 seconds the second time to start “grafana”. This means +/- 2%.

“Systemd” is faster than “sysv-init”.

With “sysv-init” it took the first time 54.8 seconds until “grafana” started compared to 39.8 seconds the second time around. This means the first time it took 38% longer, or the second time 27% less, which is significant.

“Systemd” took the first time 36.8 seconds and 35.4 seconds the second time to start “grafana”. This means +/- 3%.

“Systemd” is faster than “sysv-init”.

Please note that I also managed to record a bit unusual “systemd” bootchart. It took the second time longer than the first time until “grafana” started. It was 40 versus 47.6 seconds. Is it some kind of random boot time caused by “systemd” recalculating dependencies if not instructed otherwise? Or is it something more interesting like bootchart suddenly showing kernel modules as well? I let it up to you to come up with a theory.

Here are the charts:

With “sysv-init” it took the first time 48.8 seconds until “grafana” started compared to 39.5 seconds the second time around. This means the first time it took 23% longer, or the second time 19% less, which is significant.

“Systemd” took the first time 35 seconds and 36 seconds the second time to start “grafana”. This means +/- 3%.

“Systemd” is faster than “sysv-init”.

sys-v: booting for the first time

The biggest difference seems to be between “prelink with PIE” (66.5 seconds) and “prelink – PIE disabled” (48.8 seconds), which means 36% slower or 27% faster. This is significant.

Please note: “prelink” can only work when PIE is disabled, which kind of makes sense.

sys-v: booting, but not first time anymore

This difference is between 0.3 and 0.1 seconds, which is somewhat strange compared to what we just saw above with first-time boot. Maybe not many dynamically linked libraries are used? It is noteworthy to mention: “prelink with PIE” and “prelink – PIE disabled” behave identically at 39.8 seconds. “prelink – PIE disabled” behaves best with 39.5 seconds, but the difference is only +/- 0.7%

systemd: booting for the first time

The biggest difference, just like with “sysv” and also according to theory is between “prelink disabled – with PIE” (36.8 seconds) and “prelink – PIE disabled” (35 seconds), which means roughly +/- 5% – far less significant than with “sysv”.

systemd: booting, but not first time anymore

The biggest difference is between “prelink with PIE” (36 seconds) and “prelink disabled – PIE disabled” (33.8 seconds), which means approximately +/- 6%. prelink with PIE has no files prelinked, so it looks like it’s the overhead of PIE that slows down things.

Conclusion

We need to distinguish between first-time boot and all the other boot cycles, since the first time additional scripts are executed and stuff is done which needs extra time. Although with SysV init an improvement of 27% with prelinking at the costs of removing PIE seems quite impressive changing to systemd gives you an improvement of 45%. If you use systemd with prelink and disable PIE you’ll even get a 49% improvement.

If we look at the other boot cycles we are with SysV init at 39.8 seconds worst-case. Without PIE and with prelink we gain a whopping 0.75%, which is not worth mentioning I would say. Like before, by switching from SysV init to systemd we’ll get a 9.5% improvement and with prelink and without PIE it’s 15%.

Appendix

If you want to read about the Yocto Project® kernel tooling check it out here. If you want to learn more about how Embedded Linux works plus some Linux with additional real-time, have a look here. To learn more about the Yocto Project® give it a try here.

Upcoming Events

Our 3 points

of differentiation

We provide host and target hardware during all our teaching.

Three or more people from the same company? We provide private customized training – consulting included.

Subject matter experts develop high-quality, job-related, up-to-date, authentic courseware.