[systemd-devel] Reduce loading time (size) of init program (systemd)

[Feng Tang]

On Mon, Sep 23, 2019 at 05:37:34PM -0700, Auke Kok wrote:
> 
> On 9/16/19 7:14 AM, Paul Menzel wrote:
> >In his talk*Linux kernel fastboot on the way*  at this years Linux
> >Plumbers Conference [1][2], Feng Tang (CCed) has the notes below on
> >the slide for userspace/systemd.
> >
> >>• Systemd is ~1.5MB - the loading time for emmc is 100ms> • Can we use a small lightweight “init” program, which starts
> >>   target programs in parallel and readahead to preload libraries
> >>   and executables?
> >Are you already aware of these issues? If yes, have you ideas or
> >suggestions how to solve this? Maybe something to discuss at this
> >weeks All System Go! 2019.
> 
> Chiming in here
> 
> The benefits of doing that often don't outweigh the cost. Readahead is
> *difficult* and very much impossible to get right for a generic situation,
> so in many cases it has stopped being used. The only place e.g. ClearLinux
> uses it now is for targeted use cases where it makes sense (in our case, the
> desktop, because GNOME is ... monstrous). For typical cloud and bare metal
> situations and even VM instances, readahead doesn't appear to be useful at
> all.

Thanks Auke for the detailed explanation!

I agree this is a problem between general solution vs specific
HW/requirement, and also a balance between the 100ms and extra
complexity (plus maintaining effort).

I think it is worth trying for your own product if it really cares
about the 100 ms. My colleagues did added some codes to get the
time back, but the codes are too hacky and platform specific to be
upstreamed.

Thanks,
Feng

> 
> Despite loading time for eMMC being 100ms,  I've not seen the actual loading
> time of systemd be an issue. The worst thing at boot that can happen is that
> some process starts writing a lot (journal rotating, for instance), and is
> far more detrimental to boot time from my experience.
> 
> I like Feng's slides, but, it's not the first time that things were proposed
> that didn't pan out as much as we thought it did.
> 
> Auke
> 
>