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

[Scott James Remnant]

Thanks for the reply!

On Mon, May 9, 2011 at 11:04 AM, Lennart Poettering
<lennart at poettering.net>wrote:


> On Mon, 09.05.11 09:10, Scott James Remnant (scott at netsplit.com) wrote:
>
> > 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.
>
> We can now boot a resonably complete GNOME userspace in less than
> 1s. Given that that is the *total* these days, I really don't
> understand why you are concerned about the startup speed of individual
> service, and fear timeouts there.
>
> Because that's on a machine with plenty of L1/L2 Cache, take that away and
this becomes a big concern. Especially if 1s is a target boot time ;-)

> 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.
>
> X itself is really fast these days. While there's room for improvement
> it's far from the biggest speed bump right now. (LVM is)
>
> LVM isn't on our system. X is the biggest bump along with Chromium.

> 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 :-(
>
> Well, there's more than 30 years research in modern CPU and IO scheduler
> technology for the kernel. Instead of second guessing those from
> userspace I'd just entrust them that they pick something like the
> optimal order. And if they don't, then go and optimize them for the new
> workloads, don't bypass them by scheduling things in userspace.
>
> I'm glad you answered this way, because my thinking was in this direction
too. The scheduler isn't that great in Linux at times, as we all know,
because it lacks information about what's important. Since the kernel is
able to schedule efficiently by cgroup, the ideal seems to be to start
everything at once *but with different priorities* so that the services come
up in something approaching a sane order.

We did something like this back in Ubuntu, all fsck processes are started
simultaneously and we used I/O priorities to ensure only one was running at
a time for any given physical disk. This worked awesomely well.

Obviously this "startup priority" isn't the same as the eventual priority
you'd want the service to settle at, you'd want it to be pretty flexible -
perhaps even changing a few times.

> 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?
>
> Ignoring that X currently is not socket activatable I see no issue here
> at all.
>
> Really, this came as a surprise to me - don't all clients initially connect
to X via its socket?


> Also, note that launchd on MacOS does the same thing (including spawning
> X like this for X clients). They build their whole OS like this. And it
> works really really really well there. All experience with launchd and
> systemd tells the same story: socket activation is awesome. Plain awesome.
>
> You've never had to reboot an iPhone, have you?

You need other entertainment while it does so, a copy of the Lord of the
Rings sometimes suffices.

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