On Mon, 09.05.11 19:49, Scott James Remnant (sc...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
