Firefox OS/Performance/Boot Sequence Optimization

Initial Ideas

• Minimize data loaded by boot loader.
  • Compacting vmlinuz/zImage by moving compiled-in drivers to modules.
  • Minimize initial ramdisk if there is one.
  • Minimize kernel cruft by excluding all unneeded drivers.
  • Strip the kernel and all modules.
• Minimize init launch sequence.
  • Make init only launch the bare minimum for b2g process to launch.
  • Ideally, init will only launch b2g.
• B2G start-up sequence.
  • Remove all synchronous external dependencies from B2G start-up sequence.
    • Kernel modules must be lazy loaded as needed.
    • Any sync waits on daemons must become async. Start-up b2g pieces as daemons finish launching.
    • Minimize start-up initializations.
      • Global statics need to be minimized as their constructors are run before main().
      • Global singletons must be initialized as needed.
• Homescreen start-up.
  • Minimize _init() code to bare minimum.
  • Maybe freeze the homescreen app into a memory image that can be loaded and unfrozen instead of launching the app every time.
  • Eliminate dependency on enumerating installed apps on launch.
    • Cache the list in local storage?
    • Cache the list in the frozen memory image?
    • Speed up mgmt.getAll()

The Plan

FirefoxOS/Performance/Boot_Profiling

Bootchart

Some example preliminary data collected via bootchart here.

To enable the collection of bootchart data in FireFox OS one must build init with the following environment variable set.

INIT_BOOTCHART=true

Once init has been replaced on the device (see process here), to enable logging one simply creates a file |/data/bootchart-start| on the device containing an integer representing the number of seconds for which bootchart should collect data, and then reboot the device.

Bootchart data is pulled from the device with the system/core/grab-bootchart.sh script, and presented in the form of a bootchart.tgz file. With the data collected one can then generate graphs by invoking:

java -jar bootchart.jar -f eps bootchart.tgz

Without the |-f eps| parameters, the default is for a PNG to be generated. The SVG format is also supported.

Note that the charts generated by the stock bootchart.jar do not seem to include disk stats. This is because it does not recognize the mmcblkNpM format of partition names, and this can easily be fixed in the bootchart source code ( in particular, at |bootchart-0.9/src/org/bootchart/parser/linux/ProcDiskStatParser.java| ).

Data

Baseline statistics

These are some stats collected for the purposes of establishing a baseline. Things are organized as follows:

  repo-state        -> Information about the state of the source tree that applies to this experiment.
                       Note that things such as changes in init.rc, kernel arguments would not be visible in this

  N/                -> Each of the numbered directories represent one sample of data

  N/bootchart.N.tgz -> Bootchart archive encapsulating the data that was collected

  N/kmsg.N          -> A dump of the kernel logs of the device
                       Contains timestamp for when init has started, and time stamp for when b2g.sh is run by init
                       (and misc. other component initialization)

  N/logcat.N        -> A dump of the android logs of the device
                       Contains timestamp of when b2g has started (which is also useful to synchronize with kernel log times)
                       (since logcat logs time absolutely, and kmsg as an offset from startup

  N/rebootstamp.N   -> Local unix time recorded directly after an adb reboot to approximate time of boot

  N/synchstamp.N    -> Kernel logs are time since boot and so are the process start times, this file contains the local time and the current device
                       uptime so that one may determine when the kernel logs were initialized

For this and future data collection, at least 30 trials will be recorded. Also in the root directory there are a few randomly selected trials for which charts were generated for quick reference.

A rough idea of what we are seeing currently, as well as empirical hypotheses (Have i found my 5 seconds yet?):

• B2G starts after roughly 8s of mysterious "stuff"
• It has been noted that time between 5s and 8s is likely script execution up until |class_start main| in the init.rc
• Vertical comes up around 16s, however it does not seem to actually do anything until several seconds after that.
• As well it seems init is only really alive at 4 seconds anyway (based on inserted kernel log output)

• As such it is likely that
  • -3.5s = bootloader + Early kernel
  • 0s = kernel timing initialized
  • ~4.5s = init main
  • 7~8s = B2G
  • ~14s = (Nuwa)
  • ~16s = Vertical

Of course, more concrete data will be explored later, but that is the general gist of things

References

Firefox OS Bootup Procedure