[systemd-devel] startup performance

[Kay Sievers]

On Mon, Oct 8, 2012 at 3:36 PM, Allmeroth, Robert
<robert.allmeroth at harman.com> wrote:

> While playing around with systemd and our automotive setup we found that
> systemd checks some kernel features at startup (from systemd 33).
>
> static const char * const kmod_table[] = {
>         "autofs4", "/sys/class/misc/autofs",
>         "ipv6",    "/sys/module/ipv6",
>         "unix",    "/proc/net/unix"
> };
>
> If they are not available – they are modprobed.
>
> The problem is that any modprobe takes ~1 second, which kills our startup.

Really? What's the reason for that? Are you sure that the time is
spent in the kernel, and not something is messed up in userspace?

> If we compile these features into the kernel, the kernel boot time
> increases.

What are the numbers here? Mind creating a kernel boot init chart with:
  scripts/bootgraph.pl

We have never seen any such issues with 'dead' modules like they are,
only with hardware and synchronization of such involved.

> Question(s):
>
> Are these kernel features really needed in the early startup phase?
>
> I agree to ‘unix’ but in an automotive environment  ‘ipv6’ and ‘autofs4’
> are typically needed at a later point in the startup (or not needed at all).

On-demand loading of autofs would probably work when the device node
is accessed.

Not sure if on-demand loading of ipv6 would work.

> Is it possible to provide them as unit files so that they can be loaded if
> really needed?

I doubt that makes much sense, we either find out what's wrong with
them compiled-in, or why the modprobe takes that unusual long. Or we
rely on them to be loaded on-demand. If on-demand loading does not
work reliably, we should not try to do things in the background, it
only asks for races and synchronization problems.

Kay