[systemd-devel] Bootchart speeding up boot time

[Kok, Auke-jan H]

On Fri, Feb 19, 2016 at 7:15 AM, Martin Townsend
<mtownsend1973 at gmail.com> wrote:
> Hi,
>
> I'm new to systemd and have just enabled it for my Xilinx based dual core
> cortex A-9 platform.  The linux system is built using Yocto (Fido branch)
> which is using version 219 of systemd.
>
> The main reason for moving over to systemd was to see if we could improve
> boot times and the good news was that by just moving over to systemd we
> halved the boot time.  So I read that I could analyse the boot times in
> detail using bootchart so I set init=/..../bootchart in my kernel command
> line and was really suprised to see my boot time halved again.  Thinking
> some weird caching must have occurred on the first boot I reverted back to
> normal systemd boot and boot time jumped back to normal (around 17/18
> seconds), putting bootchart back in again reduced it to ~9/10 seconds.
>
> So I created my own init using bootchart as a template that just slept for
> 20 seconds using nanosleep and this also had the same effect of speeding up
> the boot time.
>
> So the only difference I can see is that the kernel is not starting
> /sbin/init -> /lib/systemd/systemd directly but via another program that is
> performing a fork and then in the parent an execl to run
> /lib/systemd/systemd.  What I would really like to understand is why it runs
> faster when started this way?


systemd-bootchart is a dynamically linked binary. In order for it to
run, it needs to dynamically link and load much of glibc into memory.

If your system is really stripped down, then the portion of data
that's loaded from disk that is coming from glibc is relatively large,
as compared to the rest of the system. In an absolute minimal system,
I expect it to be well over 75% of the total data loaded from disk.

It seems in your system, glibc is about 50% of the stuff that needs to
be paged in from disk, hence, by starting systemd-bootchart before
systemd, you've "removed" 50% of the total data to be loaded from the
vision of bootchart, since, bootchart cannot start logging data until
it's loaded all those glibc bits.

Ultimately, your system isn't likely booting faster, you're just
forcing it to load glibc before systemd starts.

systemd-analyze may actually be a much better way of looking at the
problem: it reports CLOCK_MONOTONIC timestamps for the various parts
involved, including, possibly, firmware, kernel time, etc.. In
conjunction with bootchart, this should give a full picture.

Auke