<div>Thanks for the reply!</div><div><br></div>On Mon, May 9, 2011 at 11:04 AM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>></span> wrote:<br><div class="gmail_quote"> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, 09.05.11 09:10, Scott James Remnant (<a href="mailto:scott@netsplit.com">scott@netsplit.com</a>) wrote:<br> <br> > This seems to assume that it's a free cost to start a service or process and<br> > have it block on a socket. But that isn't true, to get to the point where it<br> > connects to the socket, that service or process first has to be loaded from<br> > disk, its shared libraries mapped and relocated, it probably has to do a<br> > bunch of initialization including reading its own configuration files,<br> > etc.<br> ><br> > That's fine for "low priority" services out of the critical path for user<br> > interaction, but not for services we need as fast as possible.<br> <br> </div>We can now boot a resonably complete GNOME userspace in less than<br> 1s. Given that that is the *total* these days, I really don't<br> understand why you are concerned about the startup speed of individual<br> service, and fear timeouts there.<br> <div class="im"><br></div></blockquote><div>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 ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"> > The best example I can think is the X server itself. It's pretty much the<br> > definition of the critical path. Everything started before the X server are<br> > those basic system components needed to start the X server, I understand in<br> > systemd that this core part would be a different target to the X part and a<br> > dep of it. Everything started after the X server is up are components of the<br> > user's session that aren't totally critical for them to login or use their<br> > computer.<br> <br> </div>X itself is really fast these days. While there's room for improvement<br> it's far from the biggest speed bump right now. (LVM is)<br> <div class="im"><br></div></blockquote><div>LVM isn't on our system. X is the biggest bump along with Chromium.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"> > Firstly we have to spawn the X server, load the executable, map and relocate<br> > shared libraries, all of that jazz. You don't want anything else happening<br> > on the system alongside this, and you most certainly don't want every X<br> > client (Chromium/Firefox!) being loaded at the same time. The default<br> > behaviour of systemd seems to be to do just this :-(<br> <br> </div>Well, there's more than 30 years research in modern CPU and IO scheduler<br> technology for the kernel. Instead of second guessing those from<br> userspace I'd just entrust them that they pick something like the<br> optimal order. And if they don't, then go and optimize them for the new<br> workloads, don't bypass them by scheduling things in userspace.<br> <br></blockquote><div>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.</div> <div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Lastly there's the processes you'd start after X is up and services are</div> <div class="im"> > connecting to it; again I assume this would be a different target - how<br> > would systemd know that X, and the critical X services/processes are fully<br> > up and that it can begin starting these. The important thing here is user<br> > latency - the startup of these services need to not noticeably impact system<br> > performance - not as simple as prioritization because the service itself may<br> > well need a different priority once its up. Any thoughts here?<br> <br> </div>Ignoring that X currently is not socket activatable I see no issue here<br> at all.<br> <br></blockquote><div>Really, this came as a surprise to me - don't all clients initially connect to X via its socket?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Also, note that launchd on MacOS does the same thing (including spawning<br> X like this for X clients). They build their whole OS like this. And it<br> works really really really well there. All experience with launchd and<br> systemd tells the same story: socket activation is awesome. Plain awesome.<br> <br></blockquote><div>You've never had to reboot an iPhone, have you?</div><div><br></div><div>You need other entertainment while it does so, a copy of the Lord of the Rings sometimes suffices.</div><div><br></div><div> Scott</div></div>