<div dir="ltr"><div><div>Hi,<br><br></div>Thanks for your reply.  I wouldn't really call this system stripped down, it has an nginx webserver, DHCP server, postgresql-server, sftp server, a few mono (C#) daemons running, loads quite a few kernel modules during boot, dbus, sshd, avahi, and a bunch of other stuff I can't quite remember.  I would imagine glibc will be a tiny portion of what gets loaded during boot.<br></div><div>I have another arm system which has a similar boot time with systemd, it's only a single cortex A9 core, it's running a newer 4.1 kernel with a new version of systemd as it's built with the Jethro version of Yocto so probably a newer version of glibc and this doesn't speed up when using bootchart and in fact slows down slightly (which is what I would expect).<br></div><div>So my current thinking is that it's either be down to the fact that it's a dual core and only one core is being used during boot unless a fork/execl occurs? Or it's down to the newer kernel/systemd/glibc or some other component. <br><br>Is there anyway of seeing what the CPU usage for each core is for systemd on boot without using bootchart then I can rule in/out the first idea.<br><br></div><div>Many Thanks,<br></div><div>Martin.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 22, 2016 at 6:52 PM, Kok, Auke-jan H <span dir="ltr"><<a href="mailto:auke-jan.h.kok@intel.com" target="_blank">auke-jan.h.kok@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Feb 19, 2016 at 7:15 AM, Martin Townsend<br>
<<a href="mailto:mtownsend1973@gmail.com">mtownsend1973@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I'm new to systemd and have just enabled it for my Xilinx based dual core<br>
> cortex A-9 platform.  The linux system is built using Yocto (Fido branch)<br>
> which is using version 219 of systemd.<br>
><br>
> The main reason for moving over to systemd was to see if we could improve<br>
> boot times and the good news was that by just moving over to systemd we<br>
> halved the boot time.  So I read that I could analyse the boot times in<br>
> detail using bootchart so I set init=/..../bootchart in my kernel command<br>
> line and was really suprised to see my boot time halved again.  Thinking<br>
> some weird caching must have occurred on the first boot I reverted back to<br>
> normal systemd boot and boot time jumped back to normal (around 17/18<br>
> seconds), putting bootchart back in again reduced it to ~9/10 seconds.<br>
><br>
> So I created my own init using bootchart as a template that just slept for<br>
> 20 seconds using nanosleep and this also had the same effect of speeding up<br>
> the boot time.<br>
><br>
> So the only difference I can see is that the kernel is not starting<br>
> /sbin/init -> /lib/systemd/systemd directly but via another program that is<br>
> performing a fork and then in the parent an execl to run<br>
> /lib/systemd/systemd.  What I would really like to understand is why it runs<br>
> faster when started this way?<br>
<br>
<br>
</span>systemd-bootchart is a dynamically linked binary. In order for it to<br>
run, it needs to dynamically link and load much of glibc into memory.<br>
<br>
If your system is really stripped down, then the portion of data<br>
that's loaded from disk that is coming from glibc is relatively large,<br>
as compared to the rest of the system. In an absolute minimal system,<br>
I expect it to be well over 75% of the total data loaded from disk.<br>
<br>
It seems in your system, glibc is about 50% of the stuff that needs to<br>
be paged in from disk, hence, by starting systemd-bootchart before<br>
systemd, you've "removed" 50% of the total data to be loaded from the<br>
vision of bootchart, since, bootchart cannot start logging data until<br>
it's loaded all those glibc bits.<br>
<br>
Ultimately, your system isn't likely booting faster, you're just<br>
forcing it to load glibc before systemd starts.<br>
<br>
systemd-analyze may actually be a much better way of looking at the<br>
problem: it reports CLOCK_MONOTONIC timestamps for the various parts<br>
involved, including, possibly, firmware, kernel time, etc.. In<br>
conjunction with bootchart, this should give a full picture.<br>
<span class="HOEnZb"><font color="#888888"><br>
Auke<br>
</font></span></blockquote></div><br></div>