[systemd-devel] Significant speedup of systemd boot time with CONFIG_HZ=1000

[Kok, Auke-jan H]

On Mon, Nov 5, 2012 at 7:19 AM, Henrik Grindal Bakken <hgb at ifi.uio.no> wrote:
>
> Hi.  I'm setting up a systemd system with a Linux-from-scratch-ish
> distro on a multi-core platform.
>
> For a while, I was rather unhappy with the boot times I was seeing,
> but after changing CONFIG_HZ from 100 to 1000, that changed
> dramatically.
>
> My userspace components (i.e. systemd + my scripts and services) used
> to take ~11s to reach multi-user.target, but after 1000hz, they use
> ~2s.  The kernel boots up significantly quicker as well.
>
> Unfortunately, I'm not at liberty to disclose too much about the
> hardware architecture, but I have boot charts from 'systemd-analyze
> plot' and a somewhat stripped-down kernel config.
>
> They are available at
>
>   http://folk.uio.no/hgb/config_hz/plot-hz100.jpeg
>   http://folk.uio.no/hgb/config_hz/plot-hz1000.jpeg
>   http://folk.uio.no/hgb/config_hz/kconfig
>
> The kernel boot time seems pretty long there, but that's partly due to
> a fairly long (intentional) delay in initramfs.

You'll get a much fuller picture if you use github.com/sofar/bootchart and
enable initcall_debug=1 at the kernel cmd line :^)

> There is also a rather peculiar delay between the startup of several
> services (dev-mqueue.mount, systemd-random-seed-load.service, etc)
> which is very regular.  Not sure why this happens.
>
> Does anyone have any insights into why we have this huge difference?

I know that systemd-random-seed-load.service is forced to load as part of
basic.target and blocks it. During this window a lot of things are going on
that can make this service take a long, long time.

You can delay them and make non-critical services for your device
part of multi-user.target and make them non-blocking to make the
delay mostly go away.

Obviously that may not work for all services though.

Auke