[systemd-devel] startup performance

[Allmeroth, Robert]

Hello,

I did some more time measuring..

If I do the modprobe on console it's much faster than from within systemd.
The measurements show that the call to
int kmod_setup(void) {
  ...
  return wait_for_terminate_and_warn(cmdline[0], pid);
}
consumes nearly exactly 1 second.
[    4.990000] <30>systemd[1]: TIME: after exec_spawn: usec: 4990072
[    5.910000] <30>systemd[1]: TIME: after kmod setup: usec: 5918865

Since in the end waitid() is called blocking, my only guess is that this function sets up a timer which runs at minimum 1 second.
(We currently use eglibc from code sourcery)

Is there anyone else who observed this behavior?

<storymode on>
In general the timing constraints in the automotive environment are very strict (e.g. 2 seconds for park distance control from power-on (the beeps/rear view camera while driving backwards)). To provide that feature the CAN stack (speed and wheel sensors), busses for camera signals, etc.. need to be up and running.
So - everything which is not needed in the first 2 seconds has to be shifted to a later time. Every millisecond counts :)
<storymode off>

Best regards
  Robert

~ # busybox time busybox modprobe ipv6
[   26.820000] NET: Registered protocol family 10
real    0m 0.23s
user    0m 0.00s
sys     0m 0.23s
~ # busybox time busybox modprobe autofs4
real    0m 0.01s
user    0m 0.00s
sys     0m 0.02s
~ #

<code>
	curTime = now(CLOCK_MONOTONIC);
	log_full(LOG_INFO, "TIME: before kmod setup: usec: %lld", curTime);
                kmod_setup();
	curTime = now(CLOCK_MONOTONIC);
	log_full(LOG_INFO, "TIME: after kmod setup: usec: %lld", curTime);
</code>

<log>
[    4.920000] <30>systemd[1]: TIME: before kmod setup: usec: 4920172
[    4.920000] <31>systemd[1]: Your kernel apparently lacks built-in autofs4 support. Might be a good idea to compile it in. We'll now try to work around this by calling '/sbin/modprobe autofs4'...
[    4.940000] <31>systemd[1]: Your kernel apparently lacks built-in ipv6 support. Might be a good idea to compile it in. We'll now try to work around this by calling '/sbin/modprobe ipv6'...
[    4.960000] <30>systemd[1]: TIME: before exec_spawn: usec: 4962617
[    4.960000] <31>systemd[1]: About to execute: /sbin/modprobe -qab -- autofs4 ipv6
[    4.970000] <31>systemd[1]: Forked /sbin/modprobe as 44
[    4.990000] <30>systemd[1]: TIME: after exec_spawn: usec: 4990072
[    5.860000] NET: Registered protocol family 10
[    5.910000] <31>systemd[1]: /sbin/modprobe succeeded.
[    5.910000] <30>systemd[1]: TIME: after kmod setup: usec: 5918865
</log>




-----Ursprüngliche Nachricht-----
Von: Kay Sievers [mailto:kay at vrfy.org] 
Gesendet: Montag, 8. Oktober 2012 21:21
An: Allmeroth, Robert
Cc: systemd-devel at lists.freedesktop.org
Betreff: Re: [systemd-devel] startup performance

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