[systemd-devel] Parallel startup with sockets and without killing the machine?

[Lennart Poettering]

On Mon, 09.05.11 16:16, Gustavo Sverzut Barbieri (barbieri at profusion.mobi) wrote:

> But I do agree with you an a way to state our priorities would be awesome.
> This is what Lennart said about a future way to feed it to kernel. I
> suggested some hackish way some time ago:

I actually discussed this with a couple of GENIVI folks. They try to
optimize things for booting car computers with systemd. Here's what I
proposed to them:

systemd already has an elaborate dependency system. It's currently
mostly used for early boot, as for late boot we want people to rely on
implicit deps via socket activation. However the dep system is there,
and for embedded uses it might make sense to make a couple of late boot
deps explicit. With that information systemd would then be able to
deduce which units in the dep tree are "the most waited for". These
could then get an IO/CPU boost as long as they haven't fully started up
yet. We'd just iterate through the cgroup to bump their cpu/io sched
parms up, and bump them down when they signal that they started fully up
(i.e. in this case they'd have to use Type=notify instead of
Typo=simple).

So yeah, we already provide most of the tools for the finegrained
optimizing of the boot, except for the actual boosting of the perms and
the algorithm to determine "the most waited for" (which however is basic
graph theory), but that would probably be a patch of 100 lines or
less. I'd be happy to merge such a patch, but I'd like to ask everybody
looking into this, to do proper profiling first.

My guess is that this kind of microoptimization might help, but we have
a lot of other things to fix first (LVM, Ply, DDC, gdm, ...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.