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

[Scott James Remnant]

Hey, I've been reading through the documentation on systemd and the Mailing
List Archives and have had some questions, so I figured I'd post them here.
These might be fairly complicated or unusual cases, and there may be no good
answers now, and maybe no good answers ever, but I'd still like to get an
idea of what you think.

First up, parallel startup using sockets.

We know that the theory of this goes something like this: you have a service
that many other services and processes depend on, and connect to via a
socket. Rather than manually express that dependency in the configuration,
you instead have the socket created by the init daemon in advance. Now you
simply start the service and all of the other services and processes
together, and let the blocking nature of those sockets (or the software
polling a non-blocking socket) sort out the ordering for you.

This seems to assume that it's a free cost to start a service or process and
have it block on a socket. But that isn't true, to get to the point where it
connects to the socket, that service or process first has to be loaded from
disk, its shared libraries mapped and relocated, it probably has to do a
bunch of initialization including reading its own configuration files, etc.

That's fine for "low priority" services out of the critical path for user
interaction, but not for services we need as fast as possible.

The best example I can think is the X server itself. It's pretty much the
definition of the critical path. Everything started before the X server are
those basic system components needed to start the X server, I understand in
systemd that this core part would be a different target to the X part and a
dep of it. Everything started after the X server is up are components of the
user's session that aren't totally critical for them to login or use their
computer.

It's during the X startup that things get interesting. There are a few
discreet phases of it.

Firstly we have to spawn the X server, load the executable, map and relocate
shared libraries, all of that jazz. You don't want anything else happening
on the system alongside this, and you most certainly don't want every X
client (Chromium/Firefox!) being loaded at the same time. The default
behaviour of systemd seems to be to do just this :-(

Secondly you have the period after the X server has "loaded" while
it initializes but before it's "ready" to receive clients. In a perfect
world this would be fast, but we all know that it isn't. In practice the X
server takes countable seconds to do this work. This is a prime place in
boot optimization to start other services alongside while X does its thang.
But you wouldn't want to flood the system, as you don't want to delay X's
startup, just use the spare resource to get more done. Can systemd discern
"X has been spawned" and "X has initialized". Can systemd serialize services
in this period (perhaps limited to one or two starting at a time)? Can it
prioritize the order of those services in the X target?

Lastly there's the processes you'd start after X is up and services are
connecting to it; again I assume this would be a different target - how
would systemd know that X, and the critical X services/processes are fully
up and that it can begin starting these. The important thing here is user
latency - the startup of these services need to not noticeably impact system
performance - not as simple as prioritization because the service itself may
well need a different priority once its up. Any thoughts here?

Thanks,

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110509/c783da76/attachment.htm>