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

[Lennart Poettering]

On Mon, 09.05.11 19:49, Scott James Remnant (scott at netsplit.com) wrote:

> > 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 ;-)

Not to my knowledge. On my crappy Atom netbook with HDD I can boot in
13s now. Which is much better than the 40s or so before. And it's not
even particularly optimized.

> > 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.

fsck nowadays locks the originating block devices itself now on HDD,
thus serializing fscks on rotating disks.

> 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.

Yes, as mentioned elsewhere in the thread such a model of supplying the
kernel with prio data extracted from the dep tree is relatively easy to
do, and perfectly in line with systemd's design.

> > 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?

We haven't patched X for this yet. We hope to do this for the F16
cycle. See http://lwn.net/Articles/441328/

> > 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.

Well, I think we should discuss these issues when they come up in systemd
in real life. So far they are theoretical. And if they do show up we
have a large toolbox of things we could do, including the mentioned
startup CPU/IO priorization based on the dep tree. So, I think it's not
unreasonable to just lean back, and wait what comes in the knowledge
that there's a lot of low-hanging fruit.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.