On Sat, Sep 18, 2010 at 8:53 PM, Arjan van de Ven <ar...@linux.intel.com> wrote: >>> that's regurgitating systemd propaganda... but that does not make it true >>> ;) >> >> It's common sense; in my Fedora laptop I don't use cups, but it's >> started anyway. If I want to optimize the boot time for speed, I need >> to manually turn off the services I'm not really using. Presumably >> MeeGo is doing the same. However, if the process is not started at all >> (with systemd), then I don't need to turn it off. > > Since cups is talked to over networking sockets, and not used always, we use > xinetd to start it yes. > > you're getting to the whole crux of the problem: some things you need pretty > much always, and some you really want > to start on demand, because they're pretty rare.
Yes, and that's what systemd does, so you don't need to port on-demand services to xinetd (or whatever); everything is handled the same way. > 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. >>>> 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. > 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. 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. >> I can get the same on my Fedora system if I want, >> but that would require a lot of effort. And that's the point; >> constantly tweaking the services to start at the right time simply >> doesn't scale. With systemd such tweaking is not necessary. > > yeah because with systemd as is you get always the worst case (only spend > the time starting the things up that you end up always starting right > as you need them... which is the absolute worst possible time because it > creates stalls in the boot right where you can't use them). On-demand doesn't mean later, if you need 10 services to be started right after boot-time, systemd would start those services right after boottime... You demand them at time 0. >>>>> It's ok to have multiple competing technologies; that's one of the ways >>>>> innovation happens in open source.. competition. >>>> >>>> Sure, but we are not using any, so I don't see why we should assume >>>> that upstart will be used. I think both approaches need to be >>>> carefully and equally considered. >>> >>> oh trust me we are looking at all options, very very carefully. That's >>> why I >>> said that upstart currently is more likely than systemd, >>> but frankly, for 1.2 we might also just stick with what we have now.. it >>> works and is fast. >> >> Well, don't take this the wrong way, but I don't trust anyone's word >> without evidence. A document explaining such detailed analysis with >> hard numbers and preferably the tests to generate that data would be >> very welcome. That's what I would consider careful. > > MeeGo currently boots in about 8 seconds on a netbook. We're not starting > things we don't need to start. > We start all the things we know we need anyway as early as possible so we > don't need to wait on it later. Exactly the same would happen with systemd, but the dependencies would be implicit. > We know exactly where we're spending time due to our bootchart tooling, and > what it'd take to boot even faster > (it's not "go to systemd" it is "need less disk size footprint" at this > point) Surely Intel and Nokia can afford to do this bootchart tooling and optimize the booting process with sysvinit, upstart, or systemd. But some methods require less effort than others, and if other not so big companies are to use MeeGo in their products, it would certainly help to have implicit dependencies to avoid spending resources on this bootcharting process. But it's definitely true what you are saying; after the bootcharting is more or less solved, the real issues are on the services themselves and systemd wouldn't help to solve that. > For us to switch to some other method, and do a lot of work to see where it > ends up, it needs to start with knowing > that the new method gives us something that optimizes either the boot time > or (at the same boot time) the maintenance work. > with upstart we may get some interesting functionality (but we might just > implement those few things ourselves, for reasons GregKH mentioned before). > with systemd as it is today, we know we'll take 3 steps back in terms of > boot flow. I'm not ready to do that at this point... and I'm not going to > spend too much time on > analysis of systemd until that changes. Fortunately anybody else in the MeeGo community can do that :) -- Felipe Contreras _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
