On 09/18/10 13:46, Felipe Contreras wrote:
On Sat, Sep 18, 2010 at 8:53 PM, Arjan van de Ven<[email protected]> wrote:
In MeeGo we start the things we need always early, because starting them on
demand is the worst thing you can do
for startup performance (you introduce unneeded waits). But things like cups
that are only rarely used we start ondemand
using xinetd or dbus activation or whatever mechanism is appropriate.
I don't see the problem. If you need 10 services to start at init, you
tell systemd to start them at init, they all will start at the same
time, say time 0, however, as they are activated, they will traverse
the dependencies and active them as well. The end result would be the
same, except that in the upstart model somebody has to be smart about
marking the correct dependencies, but in the systemd model, the
dependencies are implicit. In fact, in all likelihood systemd would be
faster because it doesn't need to wait for the dependencies to finish
loading completely. Since upstart has explicit dependencies, it cannot
know when the dependency can really start service the dependent
requests.
this is a bit of a pipe dream, and realistically, startup really isn't
that complex when it comes to system daemons. Udev, dbus, that's it.
After that uxlaunch handles X startup. (A few low priority services are
started delayed in a background thread).
That puts systemd in a bit of an awkward light if you ask me - it
doesn't actually even have a chance of improving things, only a high
risk for negative impact when it comes to MeeGo.
Most of the rest of the meego startup code consists of silly stuff like
doing base mounts, clearing some old locks etc. and tuning some basic
parameters. That's not going away with systemd, and will most likely not
be faster if we move each and every part of that process to the "proper"
places...
But systemd turns the problem around; nothing gets started, unless
it's really used, so there's less need to customize (if any).
systemd turns it into a worst case problem unfortunately, because now you
hit the start latency ALL THE TIME.
this is what I meant with design issues; systemd's design isn't going to
give you a super fast boot. Now
maybe they'll fix it sometime in the future.... but today it makes
systemd
entirely uninteresting for booting fast.
yes it'll boot faster than the really really slow existing Fedora, but
that's not an interesting benchmark point.
the benchmark point should be the state of the art, not the worst of the
industry.
I don't know what you call "state of the art", is it a highly tweaked
sequence of events?
we have a optimized critical path, mostly achieved by removing dependencies
that were not needed...
this is a sequential series of events that we just need to get X up and
running.
Yes, you have to be smart about the dependencies because they have to
be explicitly stated.
With systemd the dependencies would be implicit.
Given the small number of true dependencies in a current MeeGo desktop,
there is not much to win here...
Then there are the non-critical path components that we start at lower
priority to fill any gaps of CPU
and IO time that might have been left by the critical path. We think we can
achieve this same split between critical and non-critical with upstart.
It's highly optimized, which is different from "highly tweaked" in that it
does not need constant tinkering.
What happens if any of those services gets updated, and suddenly
requires a new dependency? Or doesn't require something any more. You
would need to tweak the scripts again, and of course nobody will tell
you that these changes happened, you would have to follow their
development. Or what happens if you have 10 companies having custom
services started? Each one of those companies would have to tweak
their scripts.
This model requires constant tinkering and is not scalable.
MeeGo is extremely un-complex. That's what makes it start up quickly.
With systemd, since the dependencies are implicit, you don't have to
do a thing. As soon as a developer removes a dependency systemd will
do the right thing without modifications. And companies can add any
services they want without having to worry about upstart dependencies,
or having to bootchart the whole thing.
But systemd *forces* the separation of each startup component into
'properly-dependable-components' which will never approach the speed of
an un-complex solution that we have now.
People highly overestimate the complexity of starting a current desktop.
Adding systemd will drastically increase the complexity if we would do
it right (as in, actually let systemd do all the dependency sorting),
not to mention it's totally uncertain what the results will be for
stability, consistency, etc.
Auke
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
