I’m so glad that Richard Hughes took the lead on getting the system activation code in place and is trying to get it upstream into D-Bus. I think that David Zeuthen was starting to avoid me in the office. Every time I would see him I would just look at him and say “dbus activation patch?” No “hello.” No “how are you doing?” I was pretty focused. I’m sorry, David. So very sorry. But it sounds like you were busy. In any case I’m happy we’re going down the right path.
This is really going to help our story around OLPC. Right now the OLPC XO, like many machines, takes a long time to start up. Far too long. Part of this is the machine’s performance and the fact that we’re still loading a lot of legacy stuff. (RAID? Do we need to check for RAID partitions in the OLPC startup scripts? I’m guessing no!) But when both David and I started looking at it a year ago I think that we both came to the conclusion that the way that we start the desktop it was fundamentally broken, especially on that little machine. That’s why we (and when I mean we I really mean David with me looking over his shoulder) pursued things like mayflower and looking at what architectural improvements we could make to startup. That service activation patch is part of the eventual solution.
The last piece of the puzzle from where I sit is udev. The current set of Fedora startup scripts along with the way that udev is set up takes a whopping 20 seconds or so to start up on the OLPC XO. Why? Well it’s not udev, exactly. Mayflower embeds udev and it starts up in under a second. The problem appears to be the rules, the programs that are run as a result of the rules, and the way that kernel events are handled.
Right now kernel events are handled by udev. Those events are matched against rules in udev’s config files. Those config files specify certain actions. Some of those actions have terrible performance-destroying side effects. Sometimes the rules specify creating device nodes. The device nodes that we create we have to set the console permissions on those nodes. That’s done by running a program after the device is created. In addition there is a global rule that runs modprobe for every event that comes in no matter if it creates a device node. That also requires running a program. On startup, the kernel sends out anywhere from several dozen to several hundred events that result in device creation. Imagine running a program for each of those items. No do that on a machine that runs at about 466mhz. 20 seconds, indeed.
I honestly believe that we can achieve a 20 second startup time for a desktop machine in Fedora if we take an agressive notion to what startup means and continues down this path to a sane architecture. I also believe that we can get the OLPC XO machine started up in that same amount of time, if for no other reason than the number of things we need to load on startup is so much lower. I think that David has a good sense of the architectural things that need to change in udev to make it scale better. He and Kay had a roadmap at one point but I don’t know what happened to it. But it’s a key to getting to that 20 second number. I think we can do it.
