[systemd-devel] Improve boot-time of systemd-based device, revisited

[cee1]

2015-06-14 21:17 GMT+08:00 cee1 <fykcee1 at gmail.com>:
> Hi all,
>
> I've recently got another chance to improve the boot-time of a
> systemd-based device. I'd like to share the experience here, and some
> thoughts and questions.

Two more articles about boot optimization:
* http://freedesktop.org/wiki/Software/systemd/Optimizations/
* https://wiki.tizen.org/wiki/Automotive_Fast_Boot_Optimization

The interesting bits:
1. Improve a couple of algorithms in the unit dependency graph
calculation logic ...
Is there any work about this?

2. Add a kernel sockopt for AF_UNIX to increase the maximum datagram
queue length for SOCK_DGRAM sockets.
Avoid/delay blocking depending services in socket activation case

3. Since boot-up tends to be IO bound, some IO optimization:
3.1 "consider disabling readahead collection in the shipped devices,
but leave readahead replay enabled."
3.2 "Update the readahead logic to also precache directories"
3.3 "Compress readahead pack files with XZ or so"
3.4 "Make use of EXT4_IOC_MOVE_EXT in systemd's readahead implementation."

Point 3.4 seems interesting to me: I wonder whether it works on SSD?

The readahead doesn't work very well on my experiment, I guess there's
no chance to read "ahead" - doing replay may slow down the normal boot
up procedure, e.g.
   The replaying sequence: A, B, C
   The actual requesting sequence: C, B, A
If we can figure out the requesting sequence, it can achieve real read
"ahead"[1].

4. Get rid of systemd-cgroups-agent. This requires introduction of a
new kernel interface to get notifications for cgroups running empty,
for example via fanotify() on cgroupfs.
Is there any related work in processing?

BTW, tizen seems managed to start a systemd-based system in <5s(the
updated data is 3s, according to the wiki page). Going through the
bootchart, I saw several "mount" and other commands running in the
early boot stage(see the attachment).

Since exec systemd-cgroups-agent is inefficient, exec these "mounts"
or other commands are also inefficient, especially for a system aiming
to boot up in less than 3s.

5. Both articles suggest to clean up services not used on the devices.
In my case, dev-hugepages, systemd-binfmt, etc are not used on the arm board.

It looks like systemd will evolute to a minimal linux distribution(or
the tiny core of linux distribution), IMHO, it's better not shipped
with too many units, or providing some customization options -
nowadays, systemd is not only running on PC, but also on mobile
devices.

It also looks like systemd is very dynamic, but it also has a cold
boot stage or hard coded/implicit logic, e.g.
* Branches(and the related switches: environment varibles,
/proc/cmdline, name of argv[0] ...) for "system mode" / "system mode
in container" / "system mode that's reexec from initrd" / "user
mode"...

* The EFI stuffs are not used on ARM

* Special targets, units default depend on basic target

* Logging target changes in boot up: STDERR, KMSG_OR_JOURNAL, Console
..., if lost loggings, it's not easy to know why.

* The fallback logics(e.g. a new syscall is not supported) may not be
identical to normal ones, and it's not easy to figure out such
problems.

* ...

These makes it hard to use systemd in a customized system. What I call
for is to make the cold boot logic "declarative", something like:
main.c:
log_to_A
mount_X
mount_Y

Where log_to_A maybe a macro.

This makes it friendly for customizing/debugging.

6. Tizen applies services reordering for fastboot.
The boot procedure is divided into several stages, the first stage is
started up a user interactive environment as soon as possible. They
use path to notify a stage is finished.

BTW, here, the path target is a bit similar to the property system on android:
* Systemd: When a path exists, depending services fires.
* Systemd: When a property is set to the expected value, depending
services fires.

I wonder whether a property system also makes sense in systemd's world?



-- 
1. A readahead method of employing a special device mapper target:
https://www.google.com/patents/CN102520884A
2. https://wiki.tizen.org/w/images/2/28/Bootchart-fastboot.pdf


Regards,

- cee1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tizen-bootchart.png
Type: image/png
Size: 37740 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150619/746677a3/attachment-0001.png>